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 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.
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.