Cookieless Sessions and Security

In a previous blog, I pointed out that Microsoft had created an HttpModule that mitigated the ASP.NET cannonicalization issue that was first described a couple of weeks ago. In one of the comments, Amir asked about the security issues surrounding the use of cookieless sessions.  Specifically, he was wondering if ASP.NET could tell if a request containing a cookieless session component was coming from a different browser instance or even a different location.  In brief, the answer is “No“.

When used as part of a plain text web site (i.e. no SSL), cookieless sessions are not secure at all. The session id is placed into the URL in every local link on a page.  The form of the URLs would not be as follows:  http://domain.com/(sessionid)/Page.aspx. This session id is not automatically tied to a specific browser instance or even the IP address of the initial request.  There is no way that I'm aware of to tie the request to a browser (other then using cookies ;). And while a session can be associated to an IP address, this requires some additional work on your part, in the form of an HTTP Module.  The association between session Id and IP address could be done by generating a hash of the IP address for the request (Request.ServerVariables ["REMOTE_ADDR"]) and the session id and using the resulting value to access the session variables.  However, this solution doesn't take into consideration the case where people are behind a proxy that causes the IP address to change from request to request. For this, you might want to just use the first two components of the IP address, since these are not normally varied by the proxy. But if the spoofer is on the same subnet...  As you can see, all in all, this is a difficult problem to solve.

I should probably mention that cookie-based session suffer from the same problem.  There is nothing inherent in how cookied sessions work that makes them safer than their cookieless counterparts.  A hacker can easily create a request that includes a spoofed cookies containing a hijacked session identifier.  But at least a cookie-based session solution can use SSL to encrypt the entire request.  Since the session is not included in the URL directly, it is not easily accessible if the request/response gets hijacked.

So to summarize, while cookieless sessions are nice in theory, in practice they really should only be used on sites where every page is accessed through SSL.  And the implementation should be customized to ensure that a portion of the IP address is used to verify the originating IP address of subsequent requests corresponds to the original request.