Content Security Policy for ASP.net MVC

In the last article we talked a bit about Content Security Policy. Now let’s see how to quickly apply it to an ASP.net MVC project.

The ASP.net MVC project have provided some extension points in the lifecycle of a request which allow you to hook in almost as if you’re using AOP.  The one we’re interested in today is the global action filter. This is fired for every request and is an ideal place to put in a hook for adding HTTP headers.

First we create an action filter attribute which extends ActionFilterAttribute

As you can see here I’ve put in all the different headers we talked about yesterday. You could make this more efficient by checking the browser and only sending the response which suits. That is kind of a pain to do as CSP is still in flux on most browsers. In a couple of years you will probably be able to only send one header.

Next we tie it into ASP.net MVC. You can throw it into the FilterConfig.cs file like so:

(line 6 is the relevant one)

And you’re done!  I tested it by throwing in an inline alert(‘hi’) and found it to be effective. Well effective in Chrome and FireFox. IE10 still merrily threw up an alert. IE10 support is not there yet, perhaps in IE11.

There is one other good way to add CSP to an ASP.net MVC project and we’ll cover that in a future post.

Content Security Policy

A few weeks ago I was doing some research into web application security to placate some security concerns a security audit raised. For the most part what I found was the typical advice

  • Avoid SQL injection attacks by using parameterized queries
  • Use low privilege accounts to run the web server and the database
  • Don’t connect to the SQL server with an account with permissions other than dbreader and dbwriter(or your database’s equivalent)
  • Validate user input
  • HTML encode any untrusted string(so pretty much everything)
  • Avoid using dynamic SQL

One relatively new development I hadn’t heard of was using a technique called Content Security Policy. To understand the purpose of CSP you first need to know a little bit about what comes down the line to you from the web server and how the browser handles it.

For many years, until Chrome came a long a messed it all up, the first 7 characters of every URL you saw was http://. This was a protocol identifier just like ftp:// or smb://. Chrome dropped showing it, something I agree with entirely. The protocol HTTP is the language which web servers speak. One of the things which HTTP defines are things called headers. These headers provide meta-information related to the request or the response. For the most part you can be a web developer and never look at HTTP headers. It is the headers which contain POST parameters as well as Accept-Types and Content-Types. The body of the HTTP response contains the HTML, CSS and JavaScript which define the page. Within that markup you can define external resources to load be they images, scripts or style sheets.

CSP is another header which describes the behaviour of the browser when it comes to loading the external resources and processing internal scripts. There is a wide variety of things which can be done using CSP but the most useful is to block the execution of inline JavaScript.


How is my JavaScript going to get run if I can’t have it inlined? Well pretty simply you make all of your javascript included from external files.


Because one of the most common attacks against sites it to inject some nefarious JavaScript in a way that it is rendered out when other users are logged in. By doing so you can grap their cookie information or information on the page. Think about a site with a comment system, if a bad guy injects some javascript code which can run in the context of other users then they can perform any action that the logged in user can. If all your JavaScript comes from static JavaScript files then there is no attack vector to exploit.

To get this working you’re going to need to add 3 different headers to your site. This is because the various browsers have differing levels of support for CSP.

Content-Security-Policy: script-src 'self'  
X-WebKit-CSP: script-src 'self'  
X-Content-Security-Policy: script-src 'self'  

The first line is the policy as defined by the W3 standard, it is supported only by chrome and even then only by version 25+. The second version works in older WebKit based browsers. The third is supported by FireFox and IE10+. The support for CSP across browsers is not fantastic. At the time of writing there is support for about 55% of users.

There are quite a few rules you can use in the CSP. The rules above require that all your scripts come from your domain. If you make use of a CDN then you can add it to the end of the rules

Content-Security-Policy: script-src 'self' https://youcdn.com  
X-WebKit-CSP: script-src 'self' https://yourcdn.com  
X-Content-Security-Policy: script-src 'self' https://yourcdn.com```

You can also set the default so that all resources (scripts, style, images, flash, frames, fonts) are restricted to your server.

Content-Security-Policy: default-src 'self' https://youcdn.com
X-WebKit-CSP: default-src 'self' https://yourcdn.com
X-Content-Security-Policy: default-src 'self' https://yourcdn.com```

Once you get your head around not being able to use inline JavaScript then CSP is a clear win and should probably be the default when you create a new project.