Attenuare l'attacco "firesheep" nel livello applicazione?

Question

Quali sono le metodologie consigliate dalle persone per mitigare il metodo "Firesheep" per le applicazioni Web?

Abbiamo pensato a questo e dal punto di vista dell'usabilità, oltre a crittografare tutto il traffico verso un sito, la mitigazione dell'attacco può essere un po 'un problema per gli sviluppatori web.

Un suggerimento abbiamo fornito è stato quello di utilizzare i cookie percorso base, e cifrare il traffico per un percorso specifico in cui le operazioni di conto o di interazione personalizzata accade. Ciò tuttavia complica l'usabilità, in quanto il resto del sito (il non crittografato - non autenticato) non sa chi sarà l'utente.

Qualcuno ha altri suggerimenti per mitigare questo vettore di attacco, pur mantenendo un livello utile di usabilità?

Answer 1

Firesheep è nulla di nuovo. Il dirottamento della sessione è in corso da oltre due decenni. Non hai bisogno di "criptare" il tuo cookie, che è gestito dal tuo livello di trasporto. I cookie devono sempre essere un cryptographic nonce.

Di solito gli hacker impostano il proprio cookie digitandolo nella barra degli indirizzi javascript:document.cookie='SOME_COOKIE', FireSheep è per gli script kiddies che temono 1 riga di JavaScript. Ma in realtà non rende questo attacco più facile da eseguire.

I cookie possono essere dirottati se non si utilizza HTTPS per l'intera durata della sessione e questo è a parte OWASP A9 - Insufficient Transport Layer Protection. Ma puoi anche dirottare una sessione con XSS.

1) Utilizzare httponly cookies. (Fa in modo che JavaScript non possa accedere a document.cookie, ma è comunque possibile eseguire la sessione con xss)

2) Utilizzare "secure cookies" (Nome orribile, ma è un flag che obbliga il browser a rendere solo il cookie HTTPS.)

3) la scansione del applicazione web per XSS utilizzando Sitewatch(free) o wapiti (open source)

Inoltre, non dimenticare di CSRF! (Il che Firesheep non affronta)

Answer 2

Chiunque ha provato approfittando del "Web Storage" in HTML 5 per memorizzare una chiave condivisa (passato durante risposte SSL crittografato durante l'autenticazione) che viene utilizzato da javascript per modificare il cookie di sessione col tempo?

In questo modo, i biscotti rubati (in chiaro) di sessione sarebbe solo valido per un breve lasso di tempo.

La mia ipotesi è che la Web Storage è segmentata per porta (in aggiunta al proprietario), in modo che non sarebbe possibile. Basta lanciare quell'idea là fuori nel caso qualcuno voglia correre con esso.

Answer 3

Ebbene ho trovato un interessante articolo su GitHub che descrive un metodo per mitigare l'attacco Firesheep.

https://github.com/blog/737-sidejack-prevention

Answer 4

Quando i registri-in utente, memorizzare l'indirizzo IP nella sessione.

Ad ogni successiva richiesta da questa sessione, verificare che l'indirizzo IP corrisponde a quello memorizzato nella sessione.