2010-11-10 8 views
19

no he sido capaz de encontrar una guía fácil para asegurar una aplicación Ruby on Rails contra un Firesheep.¿Cómo asegurar una aplicación de Rails contra Firesheep?

En caso de que no saben, Firesheep tomas cookies de sesión si su aplicación no obliga a SSL y establece el indicador de seguro en la cookie. Tuve que buscar un poco para encontrar estas dos cosas, así que pensé en publicar lo que encontré aquí y ver si me faltaba algo más.

Paso 1 Fuerza SSL

Hay dos maneras de hacer esto que he encontrado. Uno está usando el complemento ssl_requirement, pero esto es un problema porque tiene que especificar específicamente ssl_required :action1, :action2 en cada controlador.

La forma preferible parece ser mediante el uso de estante Middleware, a través de este mensaje: Force SSL using ssl_requirement in Rails 2 app. Funciona de maravilla.

Paso 2 hacer galletas asegurar

Por esta Seguí these directions, que le diga que poner lo siguiente en su config/environment/production.rb archivo: Esto fue

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. 
    } 

todos bastante recta hacia adelante en mis rieles 2.x aplicación. ¿Yo me perdí algo? ¿Es diferente para Rails 3?

Respuesta

17

se ve muy bien para mí. Es bastante similar en Rails 3, aunque de forma predeterminada la configuración de la sesión se almacena en config/initializers/session_store.rb. Por lo general modifico la mina a ser algo como ...

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 

Y el secreto se mantiene en config/inicializadores/secret_token.rb:

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

Si tiene acceso a tu Apache (o lo que sea) config, también puede forzar el uso de SSL en ese nivel. Me parece un lugar más apropiado para hacer eso, pero supongo que no todos tienen esa opción.

+0

Gracias por la respuesta. Me estoy desplegando en Heroku para que el middleware parezca el mejor lugar para forzar SSL. –

+3

Tenga en cuenta que la opción para hacer que la cookie sea inaccesible para JavaScript es ': httponly' en vez de': http_only'. Este último fue desaprobado en Rails 2.3 (o anterior) y eliminado en Rails 3. Creo que estos cambios son para alinear Rails con Rack. –

+2

Buena respuesta, pero el uso de HTTP en pruebas y HTTPSs en producción hace que sea fácil pasar por alto problemas de contenido mixto y otros errores sutiles. –

1

En vista de que este SO posterior filas bastante alto en Google I pensé en compartir el enfoque que utilicé para asegurar una aplicación.

Si desea asegurarse de SSL, además de garantizar las cookies seguras entonces se podría utilizar un middleware rack:

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

que evaluaron las porciones de diversas opciones y ajustes de configuración para hacer esto, pero el middleware estante sentía como la mejor opción con la menor cantidad de configuración, muy fácil de implementar. Tiene algunas opciones de configuración para filtrar reglas específicas, hosts, caminos etc.

He probado que, en efecto introduzca cookies seguras correctamente y lo hace. Lo único que noté fue que solo lo hizo al cerrar la sesión e iniciar sesión de nuevo, pero eso fue usando Devise.

Cuestiones relacionadas