A couple of weeks ago, a tricky new Firefox plug-in called Firesheep made hijacking someone’s Web browsing session point-and-click simple. You should take extra precautions to ensure that nobody hacks into your online accounts when you surf on public Wi-Fi networks.
Let’s examine the issue, and take a look at what you can do as both an end user and a Webmaster.
How Firesheep works
The Firesheep plug-in listens on the network and looks for any traffic that contains a cookie, a small bit of information that a Website sends to a visitor once they have started a session (the session could begin after you have logged in, or in some cases as soon as you start browsing an online store). By eavesdropping on someone else’s cookie, the Firesheep user can jump into that person’s session without necessarily hacking into the other person’s computer.
Firesheep comes with several templates for observing the cookies of major social networking and e-commerce sites, but it is configurable to intercept cookies from any Website that hands them out. So even if your business’s Website isn’t among the supported ones in Firesheep today, your Web users may still become victims of session hijacking.
Why cookies?
Many people don’t understand the need for cookies. An analogy can help. Let’s say you call a company’s tech support hotline. You typically wait several minutes until connecting to an agent. The representative asks some authentication questions, requesting items such as your product’s serial number, the date of purchase, and a support contract number. After they have confirmed these details, they issue you an incident ID (or ticket number) for the call. When you call tech support again in the future, you can use this ID to skip the authentication steps and avoid repeating your information to the agent.
Related story – How to prevent bad guys from getting at your personal Google data
Once the support agent is convinced that you are a valid customer, you have logged on to the tech support system (albeit with a telephone instead of a keyboard), and the ticket number is merely a reference for future phone calls. In much the same way, when a Website issues a cookie, the file is usually a random collection of letters and numbers, and does not directly contain any sensitive information (such as your password).
HTTP, the protocol used on the World Wide Web, is a connectionless protocol. That means that you (or your Web browser) can ask a question and receive an answer–and that’s it. The next time you ask a question, it is as if the Website had never heard from you before. Imagine how annoyed you would be if, after having your tech support call dropped, you called back and had to explain your issue all over again and prove to the agent that you were a valid customer.
Through the use of a cookie, a Website can ask you just once for your username and password, and then provide you with a ticket number that you can present multiple times without being prompted for your password. Without cookies, you’d have to log in every time you clicked a link on Amazon.com or any other shopping site.
Stealing cookies
Now, continuing the analogy, let’s assume that you are calling tech support on a speakerphone in a crowded coffee shop. Alice, sitting at the table next to you, writes down the ticket number that the agent provides you. You could hardly indict Alice as evil; she just listened as you conducted your call on speakerphone, while other people ignored your call. A few minutes after you hang up and leave the coffee shop, Alice calls tech support and provides the same ticket number.
The support agent on the other end of the phone call will rightly believe that they are speaking with you. Even though Alice doesn’t have your serial number or date of purchase, she can jump into the middle of your tech support call and cause havoc.
When you browse a Website and it provides a cookie to you without encryption (more on that later), the situation is similar. If someone else can listen in on the network you are using, they can easily obtain your session cookies. It’s unfair to say that they’re even hacking–they’re just listening to something that you’re broadcasting as loudly as if it were on a speakerphone.
Computers are instructed to ignore all network packets that aren’t addressed to them, but that doesn’t mean software can’t alter that instruction and ask the computer to listen to all packets, regardless of addressee. If you are on a wireless network without encryption, your laptop is broadcasting all of your network traffic.
How to protect yourself
The same helpful tips from “How to Stay Safe on Public Wi-Fi” apply here as well.
Use a VPN connection if you are on a public Wi-Fi hotspot; you can find free versions, as well as a do-it-yourself version, of a secure network tunnel. If that isn’t possible, limit yourself to browsing that does not require you to log in. Assume that your laptop is connected to a Jumbotron display, and that everyone in the same Wi-Fi hotspot (the coffee shop, the hotel, the airport terminal) can see what you are doing.
Related story – Set up your own virtual private network without breaking the bank
If you still decide to go against all these security tips, at least insist that your e-commerce browsing occurs entirely over HTTPS. Yes, that S at the end is very important, as is a Web browser’s padlock icon. This means that the page you are viewing was transmitted to you via encryption. Someone listening on the network (using Firesheep or any other sniffing tool) will know what site you are connecting to, but none of the information from that page will be readable.
Here’s where things get tricky. Most Websites provide HTTPS security on sensitive pages where they ask for your password or credit-card information. Once you’re logged in, they issue you a cookie. Since they have already processed the sensitive information, however, many sites will switch you back to regular HTTP without any encryption. And they will continue to send you the session cookie on every page request, meaning that even though they had previously transmitted it securely, they’re now sending it in the open.
In early 2010, Google changed the Gmail Web-based e-mail service so that it was in HTTPS mode full-time. Previously, only the login page was over HTTPS, and all further page browsing happened over HTTP. This setup exposed the contents of users’ e-mail to anyone who could listen on the network.
Even though a Website switches you back to HTTP, you can usually switch back to HTTPS manually. Try it: Set a bookmark for https://www.facebook.com or https://www.twitter.com, for instance, so that you always use those sites’ encrypted versions. If you maintain a secure session, would-be attackers who are listening on the network (with or without Firesheep) won’t be able to steal your cookie.
Protecting your business’s website
If you are a Webmaster concerned about your members’ (or customers’) becoming victims of session hijacking, follow these rules.
1. When a user logs in, maintain the HTTPS connection
Do not switch to HTTP. In the past, certain issues with CPU performance have necessitated a switch to the less computationally intensive HTTP. But Gmail has shown that the processor impact is negligible and well worth the additional security.
2. Monitor the source IP address
If anything changes, consider it a bit suspicious and prompt the user for their password again. If someone has stolen a user’s cookie, the culprit might try to access your site from a different network. There are very few reasons for a user’s source IP address to change spontaneously during their shopping-cart checkout. (One valid reason would be that the user walked away from a Wi-Fi hotspot and their smartphone switched from Wi-Fi to a 3G connection.) The minor inconvenience of asking a customer to reenter a password is nothing next to the significant security benefits of challenging a suspicious connection.
3. Monitor Web browser characteristics
In the case of a public Wi-Fi hotspot, both the valid user and the attacker are usually masked behind the same source IP address, so rule #2 isn’t a good indicator of a session hijack. So another thing to monitor is Web browser characteristics. Every Web browser has a user agent string (an identification badge showing what browser and version a person is using). If your Web application notices that a customer started a transaction on Internet Explorer 8 running on Windows 7 but then in the middle of the session the Web browser changes to Safari 5, you should consider that to be suspicious and prompt the user for their password once again.
Since a clever attacker can fake the user agent string, try looking at other metadata–a combination of the user’s screen resolution, installed Flash version, and system time zone, for example. Panopticlick http://panopticlick.eff.org/ contends that a particular user’s mix of plug-in versions, security patch levels, and Web browser versions is almost a unique fingerprint. Any of those data points would be useful to monitor during your customer’s transaction session. 4. Make use of the HTTPONLY flag when setting a cookie.
HTTPONLY, an optional flag that Microsoft created in 2002, can append to any set-cookie header that a Web server generates. Although it is left up to the Web browser to enforce this setting (notably, Safari ignores this setting), a statement that a cookie should be accessed only by HTTP prevents the JavaScript Document Object Model (DOM) from accessing the contents of that cookie. While this measure won’t stop session hijacking and tools such as Firesheep, it is an important mitigating step to prevent future cross-site scripting.
5. Use a strong random number generator to create your session identifiers
If an attacker can guess or influence a valid user’s session ID, the intruder can easily jump into the same session. If your Web application has a very simple numerical increment for every session, an attacker could just send ID=1, then ID=2, and so on until they found a valid session. That’s why the entropy of a session ID generator is important. Search for “session entropy” and other security tips for the particular type of programming language your Web application uses.
6. Regenerate the session identifier whenever privilege levels change
On many Websites, a session begins with the visitor’s very first page access. Even if the visitor has not logged in yet, you as the site’s owner might want to track their session so that you can recommend related products to the user or track their clicks for advertising or lead-generation reasons. Many times, the session ID that a site issues to a user upon first visit remains the same after the user has logged in. This behavior is dangerous. Instead, every time a privilege level changes (moving from anonymous user to authenticated user, or vice versa), your site should regenerate the session ID.
The above items are just a small sampling of session security initiatives. You can find entire books discussing the merits of different Web-application security implementations.
If you are a Web developer, you should become familiar with session-hijacking attacks, as well as with mitigating techniques.
If you are a part-time Webmaster who just wants to protect customers from point-and-click session hijacking tools such as Firesheep, the most important advice we can provide is to enable full-time HTTPS. SSL certificates have come down in price in recent years, and you can purchase a domain-validated certificate for around $30 a year. The safety of your customers is most definitely worth 8 cents a day.
