For years, security folks — myself included — have warned about the risk of personalized web sites such as Google, Facebook, Twitter, etc. being served over plain HTTP, as opposed to the more secure HTTPS, especially given the proliferation of open wifi networks. But warnings from security freaks rarely get people’s attention. A demonstration is worth a lot more, and that’s exactly what Eric Butler did with FireSheep, a Firefox plugin that lets you instantly see who on your local network is surfing well-known sites, grab their unencrypted cookie, and “become” them on the given site. Nice work Eric!
(I must also point out Ben Laurie’s post on this topic and his always-hilarious take, “these are not the credentials you’re looking for!”)
It would also be nice if web developers could easily use a more secure approach to authentication, one that doesn’t simply send over a cookie. Something like HTTP Digest Auth, only of course *not* Digest Auth itself since that doesn’t fit in nicely with the way web sites like to manage their users’ sessions (timeouts, explicit logout, …)
Shockingly enough, SessionLock has not caught on, and I often cry myself to sleep at night wondering why… Maybe it was too complicated? So, for those web sites thinking about what to do to respond to FireSheep, I propose SessionLock Lite. It requires a modern browser, IE8+, FF3+, Safari 4+, or Chrome, and it doesn’t fully protect against FireSheep, but it makes FireSheep’s stolen sessions valid only for a very short period of time (a few seconds). Could this be a reasonable compromise?
The idea is this:
- the web site, say facebook.com, logs you in over SSL the way it currently does, and sets a secure session cookie that is only transmitted over SSL.
- when the site redirects you to the plain HTTP site, the way it currently does, the plain HTTP site opens up an invisible IFRAME onto the SSL-protected version of the site.
- the new token is communicated to the containing HTTP frame using postMessage(), which is the main reason you need a modern browser.
- the containing HTTP frame then uses this token as its unencrypted cookie.
Effectively, the SSL channel is used to refresh the session cookie very rapidly, all locally in the browser, without making SSL requests to the server other than the initial request to a very small file when the page loads. This is particularly optimized for AJAX-heavy sites like Facebook and Twitter, where the SSL IFRAME will live on for minutes or hours. While you’re using the site, someone on FireSheep can use it, too. But the moment you stop using it, they can no longer use it either.
This is not anywhere near a complete solution, but it’s a very cheap solution that costs almost nothing performance-wise, requires changing very little code, and certainly reduces the damage FireSheep-wielding attackers can cause.