19

Assume that you want to give some web users privileged access to your website, but that you are unable (or unwilling) to offer SSL to all of them - at least past the initial login page.

In this instance, is there some way to manage the user session that will negate FireSheep, but not create a painful user experience?

AviD
  • 72,708
  • 22
  • 137
  • 218
Falkayn
  • 292
  • 1
  • 7
  • See also http://serverfault.com/questions/194586/mitigating-the-firesheep-attack-at-the-network-layer – nealmcb Dec 23 '10 at 06:58
  • 2
    BTW you can't use javascript for this. Without a doubt you choose the wrong answer. – rook Jan 18 '11 at 19:05
  • I chose the answer because it points out the futility of a JS solution ("I don't think it's a good tradeoff.") and also gives some great links to other people's efforts to do the same. – Falkayn Mar 31 '11 at 02:17

5 Answers5

10

You could avoid the current Firesheep via some "security thru obscurity" scheme involving authentication via dynamic session management as discussed here. You can use "Digest Authentication" (RFC 2617), but that is still vulnerable to a MITM attack, degrades the user experience and requires the server to store your password (or a password equivalent) in the clear.

But avoiding SSL/TLS would not get around the two fundamental problems that without encryption: (1) all the private content is shared in the open, and (2) a determined attacker could figure your scheme out and defeat it.

See some cute examples of active attacks, mythbusting about performance penalties, and specific advice on deploying SSL from EFF: How to Deploy HTTPS Correctly. Note also the Stack Overflow meta discussion on why it hasn't been fixed on Stack Overflow (yet).

Note that the exposure for common sites is worse than I initially thought. E.g. note this wrinkle as the Firesheep author explains in a great post

You can’t simply avoid visiting the sites that are being attacked here. There’s an enormous amount of mixed content on the web today, such as the Facebook “Like” button, Digg’s “Digg It” button, twitter widgets, and even embedded images that are hosted on Flickr or other photo sharing sites. Every time you access any web page that includes any of this content, your browser also sends any authentication cookies you have with the request to pull down the widget.

You can at least fix the errors he discusses there (like actually invalidating session cookies when a user logs out!!).

You can also advise your users on how to protect themselves to some degree from these "sidejacking" attacks, e.g. to use a VPN or find a WPA2 wifi network (but see WPA2 issues here).

Thanks to @D.W. for a link to the best-thought-out interim approach I've seen: SessionLock Lite by Ben Adida. It at least prevents persistent hijacks by passive attackers: Benlog » keep your hands off my session cookies. Just don't stop there - engineer an SSL deployment....

Community
  • 1
nealmcb
  • 20,693
  • 6
  • 71
  • 117
8

Without a shadow of a doubt the answer is NO. You must have a completely secure transport layer in which to convey your session id. At no point can this session id be transmuted over an insecure connection, this would be a violation of OWASP A9 - Insufficient Transport Layer Protection

rook
  • 47,004
  • 10
  • 94
  • 182
  • 1
    I disagree with in principle, as security in the transport layer doesn't have to depend on the browser to do this for you. However, I agree that in practice it is futile, and as D.W. says, a poor tradeoff. – Falkayn Mar 31 '11 at 02:19
7

In principle you may be able to defend against passive attacks. But in practice it's non-trivial and not a great solution.

In principle, you can write your own encryption code in Javascript to encrypt everything on the client-side (in Javascript). The very first thing you run into is that this has poor performance, because crypto in Javascript is substantially slower than the browser's native crypto. The natural reaction is to suggest encrypting just the most sensitive data, e.g., just the user's passwords. However, this is very difficult to get right and has many subtle pitfalls:

  1. If you're not encrypting the cookies, you're vulnerable to session hijacking, and you've gained nothing. And it's not easy to encrypt the cookies or other HTTP headers from Javascript. So you'll probably be forced to end up inventing your own user authentication method and use something other than cookies (something homebrew) for session management, which is a bunch of work and easy to get wrong.

  2. If you encrypt only the password, then you may be vulnerable to CSRF attacks. An eavesdropper can still see all the page content, and in particular, if CSRF tokens are included in the link, then the eavesdropper can see all of the CSRF tokens and mount a CSRF attack. It's possible to defend against this with sufficient effort, but it requires still more work on both the client and the server, and is tricky to get right.

  3. If users can log into your site using their Facebook account, since you don't control Facebook, you can't prevent an eavesdropper from stealing their Facebook account and then logging into your site.

  4. You're still vulnerable to man-in-the-middle attacks (active attacks) that modify the page content. It would not be terribly technically difficult to modify Firesheep to use ARP hijacking, race attacks, or other methods to insert itself as a man-in-the-middle and modify all page content. Then security is lost, since the attacker can insert malicious Javascript that acts as a keylogger or otherwise steals the authentication credentials.

  5. You have to be careful that you don't lose the benefit of caching.

Now I'm not saying it's impossible. It almost certainly isn't. It is almost certainly possible to build a web site and a solution that prevents most passive attacks. But it will be complex and non-trivial. That means you'll need considerable security expertise to build it, and there's still a non-trivial chance you screw something up. It also means that the result will be expensive. And the security is inherently limited -- any scheme will be only a partial solution/mitigation -- so the value is limited. I don't think it's a good tradeoff.

If you want to read about state-of-the-art attempts to defend against eavesdropping without use of SSL, here's a great resource for you:

I'd also like to share with you some resources on making SSL perform well:

SSL isn't free -- but also keep in mind that people sometimes assume the performance impact of SSL will be worse than it actually is.

D.W.
  • 98,860
  • 33
  • 271
  • 588
  • 5
    Your lead statement ("in principle, yes") is contradicted by your text. If you write your encryption code in javascript, how do you prevent a MITM from modifying the javascript on its way to the client? But thanks for the great links! – nealmcb Jan 07 '11 at 16:00
  • Agree with nealmcb here - don't trust anything client side if the auth/session/security is that important. We know that if an attacker pwns your computer it is game over, so concentrating on the connection, an attacker could change anything sent either way. Issuing the client with secure code works for small numbers of clients... – Rory Alsop Jan 07 '11 at 20:21
  • @DW great links, thanks for those. SessionLock shows the most promise of anything I've seen so far. – Falkayn Jan 09 '11 at 03:29
  • God damn it i wish i could give this vulnerability a -1. – rook Jan 18 '11 at 19:04
2

I agree with Rook's answer. I have however an idea which you could mitigate the use of firesheep and generally all session hijacking.

My suggestion is to link a browser fingerprint to every user. If the fingerprint varies the user have to reauthenticate this fingerprint to his account.

Basically I mean to store a similar fingerprint that panopticlick.eff.org can create by just looking at your browser.

  • Everytime the fingerprint changes, make sure that the user has authenticated this fingerprint
  • If the fingerprint is not authenticated on this useraccount, reauthenticate the user.

More info about web user profiling can be found here:

Community
  • 1
Chris Dale
  • 16,149
  • 10
  • 57
  • 97
  • 1
    It seems that this attempted mitigation is targeted at simple, passive attacks. A more sophisticated attack can try to replicate the "fingerprinted" behavior exhibited by the real user's browser. If JavaScript tricks are used, then in an active attack the attacker can just change the JavaScript so it does what they want it to do. So this is part of an arms race, and some day someone will release a fancier version of firesheep which addresses the mitigations. – nealmcb Feb 04 '11 at 22:50
  • I'm just learning about this topic, but I guess one could include the javascript itself in the fingerprint. – Wout Sep 27 '12 at 15:50
  • To comment myself, I guess that could also be faked by the fake javascript. – Wout Sep 27 '12 at 15:51
1

In a word, no. In order to prevent FireSheep-style attacks, you need some way to protect your headers against even a passive observer. (After all, all information sent by the client, including ANY form of authentication criteria, is in the headers.) This means connection-level security. And, for HTTP, that means TLS or SSL protected HTTP, most commonly known as HTTPS.

There are some things that can make it harder, but there are ways around any of them.

David
  • 15,939
  • 3
  • 50
  • 73