Mitigating the 'firesheep' attack in the application layer?

Question

What methodologies do people recommend for mitigating the 'Firesheep' method for website applications?

We have thought about this and from a usability perspective, other than encrypting all traffic to a site, mitigating the attack can be somewhat of a problem for web developers.

One suggestion we came up with was to use path based cookies, and encrypt traffic for a specific path where account operations or personalised interaction happens. This however complicates usability however, in as much as the rest of the site (the un-encrypted - un-authenticated) bit does not know who the user would be.

Does anyone have any other suggestions for mitigating this vector of attack, while maintaining a usable level of usability?

Answer 1

Firesheep is nothing new. Session hijacking has been going on for more than two decades. You don't need "encrypt" your cookie, thats handled by your transport layer. Cookies must always be a cryptographic nonce.

Usually hackers just set their own cookie by typing this into the address bar javascript:document.cookie='SOME_COOKIE', FireSheep is for script kiddies that fear 1 line of JavaScript. But it really doesn't make this attack any easier to perform.

Cookies can be hijacked if you don't use HTTPS for the entire life of the session and this is apart of OWASP A9 - Insufficient Transport Layer Protection. But you can also hijack a session with XSS.

1)Use httponly cookies. (Makes it so JavaScript cannot access document.cookie, but you can still do session riding with xss)

2)Use "secure cookies" (Horrible name, but its a flag that forces the browser to make the cookie HTTPS only.)

3)Scan your web application for xss using Acunetix(free) or wapiti (open source)

Also don't forget about CSRF! (Which firesheep doesn't address)

Answer 2

Has anybody tried taking advantage of the "Web Storage" in HTML 5 to store a shared key (passed during SSL-encrypted responses during authentication) that is used by javascript to alter the session cookie over time? That way, the stolen (unencrypted) session cookies would only be valid for a short amount of time.

My guess is that Web Storage is segmented by port (in addition to host), so it wouldn't be possible. Just throwing that idea out there in case anybody wants to run with it.