
App Rails semplice per dimostrare la vulnerabilità CVE-2013-0156
== Benvenuto in Rails
Rails è un framework per applicazioni web che include tutto il necessario per creare applicazioni web basate su database secondo il pattern Model-View-Control.
Questo pattern divide la view (chiamata anche presentazione) in template "stupidi" che sono principalmente responsabili di inserire dati precompilati tra i tag HTML. Il model contiene gli oggetti di dominio "intelligenti" (come Account, Product, Person, Post) che detengono tutta la logica di business e sanno come persistere su un database. Il controller gestisce le richieste in arrivo (come Save New Account, Update Product, Show Post) manipolando il model e indirizzando i dati alla view.
In Rails, il model è gestito da quello che viene chiamato livello di mapping object-relational denominato Active Record. Questo livello ti permette di presentare i dati delle righe del database come oggetti e di arricchire questi oggetti dati con metodi di logica di business. Puoi leggere ulteriori informazioni su Active Record in link:files/vendor/rails/activerecord/README.html.
Il controller e la view sono gestiti da Action Pack, che gestisce entrambi i livelli con le sue due parti: Action View e Action Controller. Questi due livelli sono riuniti in un unico pacchetto a causa della loro forte interdipendenza. Questo è diverso dalla relazione tra Active Record e Action Pack, che è molto più separata. Ciascuno di questi pacchetti può essere usato in modo indipendente al di fuori di Rails. Puoi leggere ulteriori informazioni su Action Pack in link:files/vendor/rails/actionpack/README.html.
== Per Iniziare
Al prompt dei comandi, crea una nuova applicazione Rails: rails new myapp (dove myapp è il nome dell'applicazione)
Portati nella directory myapp e avvia il server web: cd myapp; rails server (esegui con --help per le opzioni)
Vai su http://localhost:3000/ e vedrai: "Benvenuto a bordo: stai usando Ruby on Rails!"
Segui le linee guida per iniziare a sviluppare la tua applicazione. Puoi trovare utili le seguenti risorse:
== Debug di Rails
Qualche volta la tua applicazione va in errore. Fortunatamente ci sono molti strumenti che ti aiuteranno a fare debug e a rimetterla sui binari.
La prima area da controllare sono i file di log dell'applicazione. Tieni in esecuzione i comandi "tail -f" su server.log e development.log. Rails mostrerà automaticamente le informazioni di debug e di runtime in questi file. Le informazioni di debug verranno mostrate anche nel browser per le richieste da 127.0.0.1.
Puoi anche registrare i tuoi messaggi direttamente nel file di log dal tuo codice usando la classe logger di Ruby all'interno dei tuoi controller. Esempio:
class WeblogController < ActionController::Base def destroy @weblog = Weblog.find(params[:id]) @weblog.destroy logger.info("#{Time.now} Destroyed Weblog ID ##{@weblog.id}!") end end
Il risultato sarà un messaggio nel tuo file di log simile a:
Mon Oct 08 14:22:29 +1000 2007 Destroyed Weblog ID #1!
Ulteriori informazioni su come usare il logger sono disponibili su http://www.ruby-doc.org/core/
Inoltre, la documentazione di Ruby si trova su http://www.ruby-lang.org/. Ci sono anche diversi libri disponibili online:
Questi due libri ti metteranno al passo con il linguaggio Ruby e anche con la programmazione in generale.
== Debugger
Il supporto al debugger è disponibile tramite il comando debugger quando avvii il tuo server Mongrel o WEBrick con --debugger. Questo significa che puoi interrompere l'esecuzione in qualsiasi punto del codice, esaminare e modificare il model e poi riprendere l'esecuzione! Devi installare ruby-debug per eseguire il server in modalità di debug. Con i gem, usa sudo gem install ruby-debug. Esempio:
class WeblogController < ActionController::Base def index @posts = Post.all debugger end end
Quindi il controller accetterà l'azione, eseguirà la prima riga e poi ti presenterà un prompt IRB nella finestra del server. Qui puoi fare cose come:
@posts.inspect => "[#<Post:0x14a6be8 @attributes={"title"=>nil, "body"=>nil, "id"=>"1"}>, #<Post:0x14a6620 @attributes={"title"=>"Rails", "body"=>"Only ten..", "id"=>"2"}>]" @posts.first.title = "hello from a debugger" => "hello from a debugger"
...e ancora meglio, puoi esaminare come funzionano realmente i tuoi oggetti in esecuzione:
f = @posts.first => #<Post:0x13630c4 @attributes={"title"=>nil, "body"=>nil, "id"=>"1"}> f. Display all 152 possibilities? (y or n)
Infine, quando sei pronto a riprendere l'esecuzione, puoi inserire "cont".
== Console
La console è una shell Ruby che ti permette di interagire con il modello di dominio della tua applicazione. Qui troverai tutte le parti dell'applicazione configurate, proprio come quando l'applicazione è in esecuzione. Puoi ispezionare i modelli di dominio, modificarne i valori e salvare nel database. Avviare lo script senza argomenti lo lancerà nell'ambiente di sviluppo.
Per avviare la console, esegui rails console dalla directory dell'applicazione.
Opzioni:
Per ricaricare i tuoi controller e i tuoi modelli dopo aver avviato la console, esegui reload!
Ulteriori informazioni su irb sono disponibili su: link:http://www.rubycentral.org/pickaxe/irb.html
== dbconsole
Puoi accedere alla riga di comando del tuo database direttamente tramite rails dbconsole. Verrai connesso al database con le credenziali definite in database.yml. Avviare lo script senza argomenti ti collegherà al database di sviluppo. Passando un argomento ti collegherai a un database diverso, come rails dbconsole production. Attualmente funziona con MySQL, PostgreSQL e SQLite 3.
== Descrizione dei Contenuti
La struttura di directory predefinita di un'applicazione Ruby on Rails generata:
|-- app
| |-- assets
| |-- images
| |-- javascripts
| -- stylesheets | |-- controllers | |-- helpers | |-- mailers | |-- models | -- views
| -- layouts |-- config | |-- environments | |-- initializers | -- locales
|-- db
|-- doc
|-- lib
| -- tasks |-- log |-- public |-- script |-- test | |-- fixtures | |-- functional | |-- integration | |-- performance | -- unit
|-- tmp
| |-- cache
| |-- pids
| |-- sessions
| -- sockets -- vendor
|-- assets
-- stylesheets -- plugins
app Contiene tutto il codice specifico di questa particolare applicazione.
app/assets Contiene le sottodirectory per immagini, fogli di stile e file JavaScript.
app/controllers Contiene i controller che dovrebbero essere nominati come weblogs_controller.rb per il mapping automatico degli URL. Tutti i controller dovrebbero discendere da ApplicationController, che a sua volta discende da ActionController::Base.
app/models Contiene i modelli che dovrebbero essere nominati come post.rb. I modelli discendono da ActiveRecord::Base per impostazione predefinita.
app/views Contiene i file template per la vista che dovrebbero essere nominati come weblogs/index.html.erb per l'azione WeblogsController#index. Tutte le viste usano la sintassi eRuby per impostazione predefinita.
app/views/layouts Contiene i file template per i layout da usare con le viste. Questo modella il comune metodo header/footer per avvolgere le viste. Nelle tue viste, definisci un layout usando il layout :default e crea un file chiamato default.html.erb. All'interno di default.html.erb, chiama <% yield %> per renderizzare la vista usando questo layout.
app/helpers Contiene gli helper di vista che dovrebbero essere nominati come weblogs_helper.rb. Questi vengono generati automaticamente quando si usano i generatori per i controller. Gli helper possono essere usati per incapsulare funzionalità per le tue viste in metodi.
config File di configurazione per l'ambiente Rails, la mappa di routing, il database e altre dipendenze.
db Contiene lo schema del database in schema.rb. db/migrate contiene l'intera sequenza di migrazioni per il tuo schema.
doc Questa directory è dove verrà archiviata la documentazione della tua applicazione quando viene generata usando rake doc:app
lib Librerie specifiche dell'applicazione. In pratica, qualsiasi tipo di codice personalizzato che non appartiene a controller, modelli o helper. Questa directory è nel load path.
public La directory disponibile per il server web. Contiene anche i dispatcher e i file HTML predefiniti. Questa dovrebbe essere impostata come DOCUMENT_ROOT del tuo server web.
script Script di supporto per automazione e generazione.
test Test unitari e funzionali insieme alle fixture. Quando usi il comando rails generate, i file di test template verranno generati per te e inseriti in questa directory.
vendor Librerie esterne da cui l'applicazione dipende. Include anche la sottodirectory plugins. Se l'app ha i Rails congelati, anche quei gem finiscono qui, sotto vendor/rails/. Questa directory è nel load path.