How to protect against Firesheep and co...

A lot of tweets and blogs are discussing how easy it is to use Firesheep to gain access to somebody his Facebook, Twitter, .. account, see the Techcrunch article for example.

You only need to download and install Firesheep from and it will install a Firefox extension. This extension will monitor the Wifi network for HTTP requests and it will sniff your session cookie when sent using HTTP.

Firesheep abuses a well-known issue from the OWASP Top 10, A9 - Insufficient Transport Layer Protection where the problem is discussed.

To summarize: to enable a statefull HTTP Session with the user, a session cookie is stored in the browser memory. When the user wants to logon, he needs to enter his username and his (weak) password. Some websites require HTTPS but a lot of applications still allow to logon using HTTP. So Firesheep can sniff the usernames and passwords of everyone in the same network. That is not new, Cain does that for the last 10 years (for most well-known protocols like FTP, HTTP, POP3, ...) but the nice thing of Firesheep is that is easily to install and exploit social networks. Additionally, Firesheep will also intercept the session cookie when the username and password are protected with HTTPS, but again most web applications redirect to HTTP after a successful logon and thus the session cookie is sent unencrypted over the network where it is a sitting duck. Firesheep will steal the session cookie and allows you to replay it in Firefox so you steal the victim his session and you bypass all authentication controls in place.

We have seen very critical web applications where we could bypass strong authentication using one-time-passwords because the session cookie was not protected!

So how can you protect against this new point-and-click attack tool? Very easy!

First of all: don't trust free wi-fi or unknown networks. These are not secure and allow an attacker to do nasty things, next to hijacking your credentials and session. If you are a corporate user, your company could enforce you to always use a VPN tunnel to your office to encrypt all data, or you could use the Anywhere+ solution of ScanSafe that will SSL tunnel all HTTP traffic to the ScanSafe towers for web filteringand malware scanning, which is another nice feature to defend against malware on a web site. 

Another solution is that the web application implement HTTPS for the entire session, so when a visitor visits the site he is redirected to the HTTPS version where a valid certificate is displayed and all data is encrypted between the user and the web server. Most developers and system administrators don't want to do this because they believe it requires performant hardware to handle the encryption, but that is not the case. HTTPS only has a small performancy issue during the HTTPS handshake, but after that the impact is neglectable.

Please read the article of the Google engineers where they discuss the impact of enabling HTTPS for all Google services: NO IMPACT!!! I quote: "If there's one point that we want to communicate to the world, it's that SSL/TLS is not computationally expensive any more. Ten years ago it might have been true, but it's just not the case any more. You too can afford to enable HTTPS for your users. In January this year (2010), Gmail switched to using HTTPS for everything by default. Previously it had been introduced as an option, but now all of our users use HTTPS to secure their email between their browsers and Google, all the time. In order to do this we had to deploy no additional machines and no special hardware. On our production frontend machines, SSL/TLS accounts for less than 1% of the CPU load, less than 10KB of memory per connection and less than 2% of network overhead. Many people believe that SSL takes a lot of CPU time and we hope the above numbers (public for the first time) will help to dispel that."

And web developers must configure their framework to use secure cookies!Because one HTTP request can contain the session ID, for example to get static data that is hosted by a sub-domain from the web application.


<forms loginUrl="Secure\Login.aspx"
requireSSL="true" ... />

For Java:

setSecure(boolean flag)
Indicates to the browser whether the cookie should only be sent using a secure protocol, such as HTTPS or SSL.

For PHP:

bool setcookie ( string $name [, string $value [, int $expire = 0 [, string $path [, string $domain [, bool $secure = true [, bool $httponly = true ]]]]]] )

For Ruby on Rails:

secure: whether this cookie is a secure cookie or not (default to false). Secure cookies are only transmitted to HTTPS servers.


Add comment