2012-04-11 10 views
6

ho un app Sinatra, che utilizza omniauth che ottiene questo errore constantantlySinatra applicazione utilizzando omniauth ottiene Rack :: Protezione :: dirottamento di sessione in IE9

attack prevented by Rack::Protection::SessionHijacking 

quando provo e il login (utilizzando un account Google) .

Funziona bene in altre versioni di IE e su chrome/firefox/safari.

La mia configurazione è

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) 

Qualcuno sa perché questo accade?

+2

Questo potrebbe essere correlato a https://github.com/rkh/rack-protection/issues/11 - se ne avete il tempo, potreste per favore entrare in quella discussione? Purtroppo non riesco a riprodurre questo problema. –

+0

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

risposta

8

Questo modulo tiene traccia di proprietà come USER_AGENT e simili (è possibile verificarle qui: https://github.com/rkh/rack-protection/blob/master/lib/rack/protection/session_hijacking.rb). Questo errore si verifica, è probabilmente dovuto al fatto che una di quelle proprietà è stata modificata durante la sessione. tenta di verificare se tutto funziona proprio con questo modulo disabilitato:

set :protection, except: :session_hijacking 
+1

Ah, disabilitando session_hijacking si impedisce l'errore. Non sono sicuro che dovrei tenerlo disabilitato per la produzione però. Sai perché si verifica solo in IE9? – zlog

+0

Questa è una buona domanda. Forse in IE9 una di quelle intestazioni è cambiata in qualche modo durante il percorso, ma ciò richiederebbe qualche ricerca. E per quanto riguarda questo modulo, la sua protezione non è così forte (tutte quelle intestazioni controllate possono essere ** facilmente ** falsificate) e * possono * essere problematiche. Ci sono altre precauzioni che potresti prendere, crittografando la chiave di sessione tramite SSL in particolare, e altre, vedi http://en.wikipedia.org/wiki/Session_hijacking – Ernest

+0

Grande, grazie! Disabilitare session_hijacking funzionerà per ora. Ho pubblicato i dump del server su http://gist.github.com/2358527, se qualcuno è curioso di sapere come cambiano gli ambienti di sessione. Mi tufferò attraverso di loro se avrò la possibilità. – zlog

0

Si potrebbe provare a aggiornare il tuo gioiello rack di protezione a v1.5.2 o 1.5.3 (l'ultima).

Hanno rimosso il rilevamento di HTTP_ACCEPT_ENCODING dalla libreria session_hijacking.