2010-11-10 8 views
19

Non sono stato in grado di trovare una guida facile per proteggere un'app Ruby on Rails contro uno Firesheep.Come proteggere un'app Rails contro Firesheep?

Nel caso non lo si sappia, Firesheep fa uso dei cookie di sessione se l'app non impone SSL e imposta il flag di sicurezza nel cookie. Ho dovuto fare qualche ricerca per trovare queste due cose, quindi ho pensato di pubblicare ciò che ho trovato qui e vedere se c'è qualcos'altro che mi manca.

Fase 1 Forza SSL

Ci sono due modi per fare questo che ho trovato. Uno sta usando il plugin ssl_requirement, ma questo è un problema perché devi specificare in modo specifico ssl_required :action1, :action2 in ogni controller.

Sembra preferibile utilizzare Rack Middleware tramite questo post: Force SSL using ssl_requirement in Rails 2 app. Funziona come un fascino.

Fase 2 fare i biscotti sicuri

Per questo ho seguito these directions, che vi dirà di mettere quanto segue nel config/environment/production.rb del file:

config.action_controller.session = { 
    :key  => 'name_of_session_goes_here', 
    :secret   => 'you need to fill in a fairly long secret here and obviously do not copy paste this one', 
    :expire_after => 14 * 24 * 3600, #I keep folks logged in for two weeks 
    :secure => true #The session will now not be sent or received on HTTP requests. 
    } 

Questo è stato tutto abbastanza straight-forward sulle rotaie 2.x app. Mi sono perso qualcosa? È diverso per Rails 3?

risposta

17

Sembra abbastanza buono per me. È piuttosto simile in Rails 3, anche se per impostazione predefinita la configurazione della sessione è memorizzata in config/initializers/session_store.rb. Io di solito tweak mia a guardare qualcosa di simile ...

MyApp::Application.config.session_store :cookie_store, :key => '_my_app_session', 
                 :secure => Rails.env == 'production', # Only send cookie over SSL when in production mode 
                 :httponly => true, # Don't allow Javascript to access the cookie (mitigates cookie-based XSS exploits) 
                 :expire_after => 60.minutes 

E il segreto è tenuto in config/inizializzatori/secret_token.rb:

MyApp::Application.config.secret_token = 'secret secrets are no fun...' 

Se si ha accesso al vostro Apache (o qualsiasi altra cosa) config, puoi anche forzare l'utilizzo di SSL a quel livello. Mi colpisce come un posto più appropriato per farlo, ma suppongo che non tutti abbiano questa opzione.

+0

Grazie per la risposta. Sto distribuendo su Heroku, quindi il middleware mi è sembrato il posto migliore per forzare SSL. –

+3

Nota che l'opzione per rendere il cookie inaccessibile a JavaScript è ': httponly' piuttosto che': http_only'. Quest'ultimo è stato deprecato in Rails 2.3 (o precedente) e rimosso in Rails 3. Credo che questi cambiamenti portino Rails in linea con Rack. –

+2

Risposta piacevole, ma l'utilizzo di HTTP nei test e HTTPS in produzione semplifica la perdita di problemi con contenuto misto e altri bug sottili. –

1

Visto che questo post su SO è piuttosto alto in Google, ho pensato di condividere l'approccio che ho usato per proteggere un'app.

Se si vuole garantire SSL e anche garantire cookie sicuri allora si potrebbe utilizzare un middleware rack:

https://github.com/tobmatth/rack-ssl-enforcer

Ho valutato un sacco di diverse opzioni e le impostazioni di configurazione per fare questo, ma il middleware cremagliera sentito come l'opzione migliore con la minima quantità di configurazione - molto facile da implementare. Ha alcune grandi opzioni di configurazione per filtrare regole, host, percorsi specifici ecc.

Ho verificato che effettivamente imposta i cookie sicuri correttamente e lo fa. L'unica cosa che ho notato era che lo faceva solo quando si disconnetteva e si collegava di nuovo, ma quello stava usando Devise.

Problemi correlati