2012-04-11 13 views
6

Tengo una aplicación Sinatra, que utiliza OmniAuth cuales constantantly obtiene este errorSinatra aplicación usando OmniAuth obtiene rack :: :: Protección SessionHijacking en IE9

attack prevented by Rack::Protection::SessionHijacking 

cuando intento conectarse (utilizando una cuenta de Google) .

Funciona bien en otras versiones de IE, y en Chrome/Firefox/Safari.

Mi disposición es

rack (1.4.1) 
rack-force_domain (0.2.0) 
rack-protection (1.2.0) 

sinatra (1.3.2) 
    rack (~> 1.3, >= 1.3.6) 
    rack-protection (~> 1.2) 
    tilt (~> 1.3, >= 1.3.3) 
omniauth (1.0.3) 
    hashie (~> 1.2) 
    rack 

omniauth-google-oauth2 (0.1.9) 
    omniauth (~> 1.0) 
    omniauth-oauth2 
omniauth-oauth2 (1.0.0) 
    oauth2 (~> 0.5.0) 
    omniauth (~> 1.0) 

Alguien sabe por qué sucede esto?

+2

Esto podría estar relacionado con https://github.com/rkh/rack-protection/issues/11 - si tiene tiempo, ¿podría participar de esa discusión? Lamentablemente, no puedo reproducir este problema. –

+0

Buena idea - https://github.com/rkh/rack-protection/issues/11#issuecomment-5066417 – zlog

Respuesta

8

Este módulo rastrea propiedades como USER_AGENT y similares (puede consultarlas aquí: https://github.com/rkh/rack-protection/blob/master/lib/rack/protection/session_hijacking.rb). Es probable que este error se deba a que una de esas propiedades se modificó durante la sesión. intenta probar si todo funciona con sólo este módulo deshabilitado:

set :protection, except: :session_hijacking 
+1

Ah, deshabilitar session_hijacking evita el error. Sin embargo, no estoy seguro de que deba mantenerlo desactivado para la producción. ¿Sabes por qué solo ocurre en IE9? – zlog

+0

Esta es una buena pregunta. Tal vez en IE9 uno de esos encabezados cambie de alguna manera durante el proceso, pero esto necesitaría un poco de investigación. Y en cuanto a este módulo, su protección no es tan fuerte (todos los encabezados marcados pueden ser ** fácilmente ** falsificados) y * pueden * ser problemáticos. Hay otras precauciones que podría tomar, en particular cifrar la clave de sesión a través de SSL, y otras, ver http://en.wikipedia.org/wiki/Session_hijacking – Ernest

+0

¡Genial, gracias! Desactivar session_hijacking funcionará por ahora. He publicado los volcados de servidores en http://gist.github.com/2358527, si alguien tiene curiosidad sobre cómo cambian los entornos de sesión. Voy a bucear a través de ellos si tengo la oportunidad. – zlog

0

Se podría tratar de actualizar su joya de protección de rejilla para v1.5.2 o 1.5.3 (última).

Eliminaron el seguimiento de HTTP_ACCEPT_ENCODING de la biblioteca session_hijacking.

Cuestiones relacionadas