6

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?

rook
  • 66,304
  • 38
  • 162
  • 239
pobk
  • 9,435
  • 1
  • 17
  • 12
  • Incidentally, if one of the moderators wants to add a tag 'firesheep' to this, because it's rather relevant. – pobk Oct 25 '10 at 17:28
  • One x-ref for [Firesheep](http://gizmodose.com/firesheep-firefox-plugin-allows-users-to-steal-passwords-hack-facebook-accounts.html). – Jonathan Leffler Oct 25 '10 at 17:40
  • possible duplicate of [Is HTTPS the only defense against Session Hijacking in an open network?](http://stackoverflow.com/questions/4017344/is-https-the-only-defense-against-session-hijacking-in-an-open-network) – rook Oct 25 '10 at 18:13

4 Answers4

7

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 Sitewatch(free) or wapiti (open source)

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

rook
  • 66,304
  • 38
  • 162
  • 239
  • Yes. It's nothing new. The New as you mention is that the skript kiddies can get in on the act. Which is why it's potentially such a problem. I want to protect my users. – pobk Oct 25 '10 at 18:07
  • @pobk You should be enabling these security features before Firesheep. This tool doesn't change anything. – rook Oct 25 '10 at 18:15
  • Our application is as secure as we can make it (it complies with PCI DSS)... We're just looking beyond at protecting our users. – pobk Oct 25 '10 at 18:21
  • @pobk The pci-dss does require regular scans, but is your web appreciation enabling the 2 cookie flags I talked about? – rook Oct 25 '10 at 18:29
  • Secure cookies are not enabled since the session is used for personalisation. We don't want to run the entire site from HTTPS... that would be a nightmare for usability. Usability and site personalisation becomes infinitely more difficult. – pobk Oct 25 '10 at 19:36
  • Confused, why is https less usable? Unless you have self-signed certificates (so don't do that then - there are cheap CAs) it's basically transparent to the end-user – telent Oct 26 '10 at 12:23
  • @pobk With this application design you will always be vulnerable to firesheep and always violating OWASP. HTTPS is the only method to protect your self. SSL is a very light weight protocol, the handshake is cached and cipher text does not add additional bandwidth. – rook Oct 26 '10 at 16:28
0

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.

Brock Adams
  • 90,639
  • 22
  • 233
  • 295
arscan
  • 111
  • 1
  • The attacker then just has to inject some javascript into one of the HTTP responses, that reveals the shared key. – caf Nov 08 '10 at 14:36
0

Well I found an interesting article on GitHub that describes a method of mitigating the firesheep attack.

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

pobk
  • 9,435
  • 1
  • 17
  • 12
-1

When user logs-in, store the IP-address in the session.

On each subsequent request from this session, check that the IP-address matches the one stored in the session.

EA.
  • 5,370
  • 2
  • 18
  • 13
  • I'm afraid that won't work. The remote IP address would be shared in the instances where firesheep would be prevalent – pobk Nov 15 '10 at 09:19
  • Even if you also store the value of the X-Forwarded-For HTTP header along with the IP-address? – EA. Nov 17 '10 at 06:11