Firesheep: What It Is And Why You Should Be Scared

Recently, there has been a lot of discussion surrounding the Firefox add-on Firesheep. Firesheep is a tool that makes it easy for its user to assume (hijack) the identity of other users on a number of popular websites. I want to take a moment to explain not only how Firesheep works, but how when you are using the Onehub site, we protect you from the vulnerabilities that Firesheep exposes.

The Internet, and the protocol it is primarily built on, HTTP, are inherently stateless, meaning that by default no information is kept on either the client or server between requests. In other words, if you request the homepage from a website, then the product page, the website has no way of knowing that these two requests came from the same person, thereby making things like user logins and shopping carts impossible to track. In order to work around this limitation, and provide the seamless experience we have all come to expect, websites place a small piece of data on each user’s computer: a cookie. These cookies (specific to each website) are sent back to the website with every browser request, and they can use the information contained therein to recognize that all of your requests are coming from you, and you alone. In essence, once you are signed-in, you are your cookie. Cookies have a bad reputation amongst some users, however they are an indespensible piece of technology, and without them the modern Internet would not function.

An Example

Let us use a simple story. Charles would like to visit to check the latest activity in his Workspaces.

Charles opens his web browser, Mozilla Firefox, and types into the location bar. On his behalf, Firefox sends a request to the servers for the homepage. In a few milliseconds the server replies with the HTML, CSS, JavaScript and images that make-up the homepage. Firefox takes this data and renders in Charles’ browser. So far so good. In order to see the latest activity, Charles will need to sign-in, and then visit the activity tab. So he clicks the “Sign In” button on the top-right of page and again, Firefox sends a request for a webpage to the servers, but this time for the sign-in screen. This is where it gets interesting.

The sign-in screen is secured via SSL/TLS (indicated by the S in the HTTPS in Charles’ browser). This ensures that the server really is who it claims to be, and encrypts all the data exchanged between Charles’ computer and the server. Confident that his email and password will not be exposed to the world, Charles fills out the form and presses enter. With the email and password in hand, the server does a few checks. It first looks in the database to see if a user with Charles’ email exists, if this is the case, it checks the password for that account against the password Charles typed in earlier. Provided both of these pieces of data match, the server replies back with the requested data, Charles’ home screen. In addition, the server provides a small piece of data in a cookie, a session identifier. This is a randomly generated string of characters, something like “a74822fdbce86b1541fec9c1f92d366f”. In addition to sending this identifier to Charles’ browser in a cookie, it is also stored by the servers. In fact, if you are signed in to right now you may look in your cookies for _onehub_session_id which will have your unique session identifier.

The session identifier functions as a stand-in for the user’s credentials, it saves Charles from having to provide this information on every single request.

Now that Charles is on the homepage, he clicks on the activity tab. Firefox again requests a specific webpage from the servers, but this time it also provides the data in the cookie, the session identifier.

The server accepts this request, and looks up the session identifier in the database. The database provides two pieces of information to the server about this particular identifier. First, if this identifier was created recently enough (you may extend the length a session identifier is valid by choosing ‘Keep Me Signed In’), and second, that it belongs to Charles. The server can now reply with the data for Firefox to render Charles’ activity page.

This type of data exchange happens millions of times per-second across the Internet and it is this same technique that lets you do everything from sharing a photo on Flickr to keeping a shopping cart on

So how does Firesheep work?

It is actually relatively simple. Most websites ( included) secure their sign-in forms with SSL/TLS. This means your email or username and password are encrypted when sent to the server. However, once a user is signed-in these sites do not encrypt the data exchanged between the browser and the server ( does). Firesheep watches all the traffic flying around on the network it is running on, like the coffeeshop which Charles is working from this morning. It listens specifically for the session identifiers for many popular websites including Facebook and Twitter. Firesheep then provides an easy way to change Charles’ session identifier to another one that Firesheep has found on the network. Charles is transparently able to assume (hijack) someone else’s identity.

How is Onehub secure?

We do two things differently than the majority of sites. First, we encrypt all traffic, all the time. This makes the session identifiers opaque to tools like Firesheep, provided the user visits the SSL/TLS secured webpage. Second, when providing the cookie to the browser, marks the cookie as ‘Secure’. The implications of this second measure are subtle. Suppose Charles visits (without the S). Without the cookie marked as ‘Secure’, Firefox would transmit the cookie to the servers unencrypted. While could redirect his browser to visit (with the S), the damage is already done: Charles has broadcast his session identifer in an insecure fasion. Firesheep and other tools would be able to intercept it before the server can instruct the browser to try again via the secure connection.

Internet Security is a tough problem, it requires education of both end-users (Charles) and system administrators (Onehub) to ensure data is not leaked. The team here at Onehub works very hard to ensure your data is safe. We will continue to monitor new threats as they arrive, and adjust our systems and policies where appropriate.

2 thoughts on “Firesheep: What It Is And Why You Should Be Scared

  1. Why is there the need to use both cookies and session?
    Just only the session (stored at's server) isnt enough?

  2. We need to know which session is yours. HTTP is stateless, so we use a cookie to keep the identifier for your session on your browser, the actual contents of the session are stored on our servers.

Comments are closed.