How to secure your cookies in ASP.NET

Most authentication systems for ASP.NET and Core use an authentication cookie for your application to tell the web server the client is successfully signed in. You have probably already seen a cookie named .ASPXAUTH in your browser. This is a cookie returned by Forms Authentication once the user is signed in. The value of the cookie contains an encrypted string that can be used to authenticate the user on subsequent requests. If a hacker somehow gets the value of the .ASPXAUTH cookie, he/she would now be able to hijack that session.

As you know, by running HTTPS only, no-one can inspect the traffic between the browser and the webserver using a man-in-the-middle attack or something similar. When you switch to HTTPS, you will need to tell it that cookies should be available over HTTPS only. 

Since a lot of cookies never need to be accessible from JavaScript, there's a simple fix. Marking cookies as HttpOnly. As the name suggests, HTTP only cookies can only be accessed by the server during an HTTP (S!) request. The authentication cookie is only there to be sent back and forth between the client and server and a perfect example of a cookie that should always be marked as HttpOnly.

To do so globally, you can include the following in Web.config

<system.web>

  ...

  <httpCookies httpOnlyCookies="true" requireSSL="true" />

</system.web>

HTTPOnly is an attribute that is provided by the server when it is setting a cookie to indicate that the cookie should not be visible to JavaScript (as a security measure); the cookie is only to be sent to the server via the Cookie request header.

The HTTPOnly attribute is only visible in the Set-Cookie response header when a cookie is set; the client will not send that attribute back to the server when it resends the cookie to the server on subsequent requests.

Browser tools that show a cookie's httponly state do so by directly examining the cookie metadata within the browser's cookie database.

Avoid TRACE requests (Cross-Site Tracing)

Marking cookies as Secure and HttpOnly isn't always enough. There's a technique called Cross-Site Tracing (XST) where a hacker uses the request methods TRACE or TRACK to bypass cookies marked as HttpOnly. The TRACE method is originally intended to help debugging, by letting the client know how a server sees a request. This debugging info is printed to the response, making it readable from the client.

If a hacker has successfully injected code onto your page, he/she could run the following script:

var xhr = new XMLHttpRequest();
xhr.open('TRACE', 'https://my.domain/', false);
xhr.send(null);
console.log(xhr.responseText);

If the receiving webserver supports TRACE requests, the request including server variables, cookies, etc., is now written to the console. This would reveal the authentication cookie, even if it is marked as Secure and HttpOnly.

Luckily, modern browsers won't let anyone make TRACE requests from JavaScript. You still want to eliminate the possibility, by updating your Web.config accordingly:

<system.webServer>
  <security>
    <requestFiltering>
      <verbs>
        <add verb="TRACE" allowed="false" />
        <add verb="TRACK" allowed="false" />
      </verbs>
    </requestFiltering>
  </security>
</system.webServer>

The verbs element includes a list of HTTP verbs not allowed.