FireSheep, at this point, is somewhat old news; even when FireSheep was released, the issue it exploits “under the hood” has been old news for a number of years. If you haven’t heard of it yet, FireSheep is a FireFox extension that greatly simplifies the process of stealing another user’s HTTP session. By simply downloading and installing FireSheep, someone with less $k1llz than a scr1pt k1dd13 can easily double-click their way into accessing another user’s Facebook, Twitter, or a variety of other accounts. The extension works by sniffing unencrypted traffic, including cookies that let applications like Facebook know that you are in fact, well, you. There are some limitations on when and where the extension will work, but nonetheless FireSheep has quickly raised awareness within the general public on the pervasiveness of the issue.
While the average person may not understand exactly how FireSheep works, awareness of the end result is fairly obvious and hits home quickly. While the extension is rigged to be an easy “point and shoot” for well known sites such as Facebook and Twitter, the concept could be easily transferred to any application that fails to send session information over a secure channel, including yours. Even though HTTPS is used to protect the login process, the cookie containing the user’s session information is thereafter sent over HTTP. With a few tweaks to FireSheep’s source it would be just as easy to “point and shoot” the extension at your app, allowing session hijacking through a few clicks.
The moral of the story? As always, layer up. If possible, use the “Secure” attribute when setting session cookies to ensure that the cookie is only passed over HTTPS. Configure your application such that it runs entirely over HTTPS, or at least anywhere that session information will be passed between the client and server. If you’re using Apache, you can use the SSLRequireSSL directive to deny access when SSL isn’t used for an HTTP request. While there are a number of measures that can be taken client-side to try and combat the threat of FireSheep, ultimately the issue lies within the service provider. Depending on the application and its surrounding infrastructure, it may be a somewhat costly endeavor to make the switch to HTTPS; as with all changes, the cost must be justified. If the benefits of end to end encryption aren’t hitting home with the right people, consider setting up a quick FireSheep demo to illustrate just how easy it is to exploit the issue. If jaws drop as you update a (volunteer) coworker’s Facebook status on the projector within 10 seconds of them logging in, you’ll know you’re in good shape.