Dr. Dobb's | Session Hijacking

Session Hijacking

Every web application is a likely target for session hijacking, but tracking IP addresses as requests are processed can help spot the ne'er-do-wells

October 11, 2004
URL:http://www.drdobbs.com/session-hijacking/184405837

Session Hijacking

As many observers and analysts report, applications are more often under attack than the network and host environment. The reason is pretty obvious: Applications wrap data, sometimes sensitive data, and can become the vehicle of infections and malicious attacks against other applications or critical parts of the system.

There are many ways a developer can leave the door of his system open to an attacker. And, likewise, there are many ways an attacker can slipstream his potentially injurious code in a poor and innocent application. One of the most common attacks is session hijacking. This attack is subtle and annoying, not so much because of the damage incurred with it-it depends on the application data deployment-but because there's not much you can do about it if you're not raising the bar (and the costs of the attack).

If you judiciously place the virtual bar of security, session hijacking can be defeated; in doing so, though, and unlike for other common types of attacks, you can't rely much on the ASP.NET infrastructure and programming model.

Session hijacking is when an attacker gains access to the session state of a particular user. Basically, the attacker steals a valid session ID (i.e., stealing a valid session cookie) and uses that to get into the system and snoop into the data.

We all agree this is a reprehensible action from an ethical point of view. Is this injurious as well? That depends on what is actually stored in the session state. Stealing a bunch of IDs pointing to database records is not a big deal per se. This information is scarcely useful because it doesn't represent an action and cannot be used to perform an action. Or, at least, not necessarily. Stealing credit-card or account information is another story. If you know all credit-card details you can go to another site and use that information to buy anything you want.

What is the security hole that leaves room for this attack? Nothing in your application. You can only program defensively (and reasonably) and avoid placing sensitive data to session. ASP.NET associates session data to incoming requests based on the session ID. ASP.NET simply ensures that the submitted session ID is valid, no matter how the request got to get it. If the attacker can either guess a valid session ID or steal a valid one, he can get in and use that (maybe yours) session state.

From an ASP.NET perspective, guessing a valid ID is virtually impossible because of the employed algorithm. (Look carefully before you take the leap and replace the session ID generator in ASP.NET 2.0.) Stealing a valid session ID is, instead, possible and under certain conditions even likely!

The session cookie can be stolen from the browser or as the result of a prior code injection attack. The session cookie contains only the session ID, but this is just what is needed to have the session state associated with the request!

ASP.NET implements no special barrier to filter stolen session IDs. You can do that by writing an additional HTTP module or, in ASP.NET 2.0, by extending the existing one to support a verification of the IP address of the requestor.

Simply put, the idea is to embed the IP address of the requestor in the cookie after the regular session module has done and the request is close to its end. On the way back, when the request comes in, the same module will check the current IP address against the stored one, and allow the request to pass in case of a successful match. To preserve compatibility, the module must also remove any extra information the regular module doesn't handle from the cookie.

Jeff Prosise has written a great article about this technique in his "Wicked Code column in MSDN Magazine, August 2004. One more warning: Cookieless sessions are of great help to attackers. If you're sensitive to security, avoid them.

Dino Esposito is Wintellect's ADO.NET and XML expert, and a trainer and consultant based in Rome, Italy. Dino is a contributing editor to Windows Developer Network and MSDN Magazine, and the author of several books for Microsoft Press including Building Web Solutions with ASP.NET and ADO.NET and Applied XML Programming for .NET. Contact Dino at [email protected].