Earlier this year, a developer named Eric Butler released a tool he called Firesheep that allows hackers to eavesdrop on unencrypted wireless networks and steal the sessions of other users who are logged on to popular websites. Firesheep allows the hacker to gain access to the accounts that users access on popular websites, including Facebook and Twitter. It works by exploiting a flaw that's been well-known, but inadequately addressed, for many years: session hijacking.

In this blog, we take a look at the mechanisms behind web authentication that make session hijacking possible, how Firesheep exploits these vulnerabilities, and the measures that website administrators, web developers, and end users can take to protect against session hijacking attacks.

Web Authentication simple run-down!

You may know that web authentication relies upon small pieces of code known as cookies to manage the sessions of logged-in users. Here's a quick run-down on how the process generally works:

1. User accesses a website that requires authentication.
2. User provides a username and password to authenticate.
3. The website logs the user in by verifying the password and provides the user's browser with a cookie that is used to uniquely identify the session.
4. The user continues to access the website. Each time he or she requests a new page, the browser sends the cookie along with the request to remind the web server that the request is part of a previously authenticated connection.

In almost all cases, web developers and website administrators use HTTPS encryption to protect step 2 of this process, knowing that someone gaining access to an individual's username and password can easily gain access to his or her account. In many cases, they then switch back to an unencrypted HTTP connection for the remainder of the web traffic, including the exchange of the cookie.

Session Hijacking Attacks and Firesheep

Enter session hijacking attacks. An eavesdropper who manages to intercept any of the communications that take place during step 4 of the process (which is trivial on an unencrypted wireless network) can easily gain access to the cookie. Once the contents of the cookie are known, he or she can create a forged HTTP request that uses the cookie to gain access to the user's account.

Many popular websites, including Facebook and Twitter, have been vulnerable to this type of attack for many years. The only barrier to widespread exploitation was a woefully inadequate reliance upon security by obscurity. A relatively small number of people had the knowledge and expertise to carry out a session hijacking attack, and they often lacked the motivation. After all, major targets such as online banking, brokerage, and e-commerce sites encrypted all of their communications. Hijacking a social networking site session just didn't seem worth the effort.

Then along came Eric Butler with Firesheep, a tool that removed the barrier to entry and put session hijacking capability into the hands of anyone capable of installing a Firefox extension. A user wishing to steal sessions simply has to connect to an open wireless network, start Firesheep, and wait for the names of vulnerable users to appear on the screen. When an attractive target pops up, the attacker simply clicks on his or her name and gains full access to the session!

Defending Against Firesheep

The best line of defense against Firesheep and other session hijacking attacks lies in the hands of web developers and web server administrators. If you develop web applications that rely upon cookies for session management, be sure that they are always managed in a secure fashion. Here are a few ways you can do that:

• Send cookies only via SSL. If you require browsers to encrypt the cookie before transmission, it won't be vulnerable to interception while in transit. This is as simple as setting the secure option in the cookie and allowing full HTTPS access to your website.
• Limit the applications that can make use of your cookies. You should also set your cookies so that their use is as restricted as possible. At a minimum, you should set them so that they are only accessible to systems in your domain using the domain option in the cookie. Ideally, you should set the cookie's use to a specific server within your domain. You can also restrict the cookie's use to specific applications in your domain by setting the path option.
• Restrict cookies to HTTPS. You can also use the httponly flag to request that browsers only submit cookies directly to the server via HTTP/HTTPS connections. This prevents an attacker from accessing the cookie via JavaScript attacks.

If you're an end user, you don't have control over the way cookies are configured, but you do have some options at your disposal:

• Limit your use of websites that do not offer HTTPS connections. You can vote with your feet by refusing to use sites that may be vulnerable to session hijacking attacks.
• Tunnel your connections through a VPN. If you're using the Internet in a risky location and are concerned about eavesdroppers conducting session hijacking attacks, connect to a VPN (virtual private network) at your workplace and use that connection to encrypt traffic that you're sending on the local network.

Media reports recently highlighted a number of tools designed to thwart Firesheep, most notably a tool called Fireshepherd that shuts down instances of Firesheep running on the local network. These tools are flawed in that they only limit the effectiveness of Firesheep as a tool but do nothing to remedy the underlying flaws in web authentication via unencrypted means. A moderately sophisticated attacker can use a network sniffing tool, such as Wireshark, to monitor traffic and steal your session without detection.

Final Thoughts

The release of Firesheep is more than just a software threat. It highlights an underlying flaw in the way many web applications conduct session management. While there are temporary solutions you can implement to limit the short-term damage done by the release of this tool, it's imperative that the web application community band together and develop long-term solutions that resolve the significant design vulnerabilities which make session hijacking attacks possible. Otherwise, we'll be just as vulnerable when the next tool rolls out.