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?
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:
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.
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.
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.
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.
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.
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....
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
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.
More info about web user profiling can be found here:
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.
