How to secure ASP.NET cookies

The release of Firesheep a week ago brought a lot of attention to a problem that has been known for many, many years: cookies sent over both secure and insecure connections to the same site. Why all the fuzz now? Well, first of all, "regular" people (as in non-geeks) can install Firesheep and start stealing Facebook sessions. With such a demonstration, people realize just how easy it is to "hack" another user's account. Secondly, we're all on Facebook, so we all feel that this affects us personally. We can relate to the risk, and it stirs our emotions. Thirdly, the media loves these kinds of demonstrations and can capitalize on the fear factor. This hack was simple enough and scaled nicely, which made it a good sell.

Now the debate goes on about Firesheep, here's a good blog post on the ethical aspects. In this post I also found a link to Microsoft's Malware center, their antivirus software apparently detects Firesheep as a hacktool. Like it really matters. Firesheep clones will pop up all over the Internet. The only viable path forward is to build websites not vulnerable to trivial eavesdropping attacks.

Firesheep has raised the bar for baseline security in web applications. Before Firesheep, you would be regarded as sloppy or lazy not to have secured your website's cookies. After the release of Firesheep, you're essentially committing a crime against your users — because now you (and they) know that cookies can easily be stolen.

If you need a basic introduction to what cookies are, check out the cookie article on Wikipedia.  The rest of this post discusses more technical aspects of cookie security.

We'll start with the solution. If you're running an ASP.NET site and all the traffic should be served over SSL/TLS, you'll want to add the following configuration to your web.config:

---

<system.web>
  <httpCookies httpOnlyCookies="true" requireSSL="true" lockItem="true" />
</system.web>

---

Include this configuration in the web.config in the application's root directory, to ensure that the cookies you are issuing are secured across your entire site. The httpOnlyCookies configuration helps protect cookies from scripting attacks, while the requireSSL setting fixes the Firesheep problem by marking issued cookies as secure. The lockItem attribute ensures that other web.config's cannot override these settings. Here's the documentation on MSDN.

Read on for an explanation on what this configuration means (yes, you should read this too).

Secure cookies
The secure attribute instructs the browser to include the cookie only in requests that are sent over an SSL/TLS connection. In effect the cookie will be missing in requests to addresses starting with http://, but will be included in requests to addresses served over https://. This attribute is read by the browser when the cookie is set, in subsequent requests the secure flag will be included in neither request nor response.

There are some implications with secure cookies. In a cleartext request (http://), the browser will not include the cookie, as it's not sent over a secure channel.  On the server side, this will appear to be a user without a session. Many webapps will then issue a new session cookie by default, which in turn overwrites the old session cookie, and the user loses his session. This is how ASP.NET works by design, upon receiving a request without a valid session cookie, ASP.NET will automatically create a new session identifier and issue a new cookie. So, be prepared for side-effects if you enable secure cookies on an ASP.NET site that contains links to http, or utilizes JavaScript that issues requests for content over http. Make sure alle links and javascript requests are to https:// content!

HttpOnly cookies
The httpOnlyCookies attribute politely asks the web browser to not share a cookie with scripts or Applets. For session cookies, this attribute should always be true. As with the secure attribute, httpOnly can only be seen when a cookie is set in a response.

Modern browsers will prohibit scripts from reading the cookie value when this attribute is set. If scripts make requests to the web application (ajax) , the browser will still include the cookie in the request, but the script never gets direct access to the cookie's value.

For e.g. a Java applet, the security effect is more notable. Requests initiated by an applet will be sent without the httponly cookie. There are several subtle effects of the httponly attribute on applets, depending on which browser and version is in use. These effects deserve a separate blog post — it's upcoming. Still, enable httpOnlyCookies on your site if you can!

Read more about HttpOnly cookies on the OWASP website.