You sit in your local WiFi hotspot, sipping your mocha. Most hotspots use a completely unsecured protocol. No passwords, no logon to the network. And no encryption. You fire up FireSheep. It watches the wireless traffic around you. A few minutes later FireSheep has accumulated enough data to snoop the Farcebook login data of the cute young thing two tables from you. It's snooping the twitter login of the advertising executive the next table over. Etc.
You click on the picture the cute young thing uses for her Farcebook avatar. You are now using her account on Farcebook. On her profile page, you can find her personal data.
Fantastic? Nope, just a simplification of something that has been going on routinely for years, but is now so much easier to do.
FireSheep isn't the only program that does this. A quick hack called idiocy runs on most Unix and Unix-like operating systems. It hijacks twitter sessions, and sends the owner of the hijacked account a tweet warning the owner about the vulnerability. It's completely automatic; you need do nothing beyond installing and running it and sipping the ocasional mocha while it does its thing.
OK, what's the defense against FireSheep et al.? The first defense for the average user is to use Transport Layer Security (TLS) (or its predecessor, Secure Sockets [SSL]) whenever possible. To do this manually, change the protocol portions of urls from "http://" to "https://". However, that doesn't work when you follow a link.
To automate the process, use an add-on that does it for you, such as Force-TLS or HTTPS Everywhere. Force-TLS requires the user to set up rules for most sites. Fortunately this appears to be fairly easy. HTTPS Everywhere doesn't require any setup, as rules for many popular sites are included. But you can roll your own.
While I did not anticipate FireSheep, I did anticipate this sort of attack. So I've been using HTTPS Everywhere for a while; that's why some of the recent links from this blog use SSL. I recommend it.
The ultimate solution is for web sites to carefully think out their security and do it right, something at which both Farcebook and Microsoft appear to be incompetent. If nothing else, use a shotgun approach by making all internal links use SSL. Using SSL for the login process and then reverting to HTTP is disastrously inadequate: the session cookie the user gets after the login is now visible to every FireSheep snooper out there. FAIL!
FireSheep is controversial. It has made "sidejacking" trivially easy. Is this a good or bad thing? If FireSheep finally rubs commercial web site PHBs' noses in the messes they've made, I for one will applaud its creators.
The other wrinkle is that even if the developer moves the session to SSL, they might forget to mark the cookie secure. So when the user goes to their old http:// bookmark they might still leak out their session cookie and be vulnerable to session-jacking.