mitigating attacks with content security policy

Firefox support for Content Security Policy (CSP) has been in the news and is now available in test builds for web developers to try. Support for CSP isn’t slated for Firefox 3.6 but is likely to be included in the release after 3.6, mostly likely called 3.7.

This post is targeted at web developers and gives a quick overview of the three kinds of attacks that CSP helps to mitigate and also gives some quick examples so developers can get a sense of how it will work for them.

In case you don’t know what our Content Security Policy code is – and based on anecdotal evidence a lot of people don’t – it’s a set of easy to use tools that allow a web site owner to tell the browser where it should or should not load resources from. In particular it aims to prevent three different classes of common attacks we see on the web today: cross-site scripting, clickjacking and packet sniffing attacks.

Cross-site scripting attacks are largely the result of a mistake made on backend web servers where someone fails to escape data that’s submitted by users. When that happens it’s possible to inject a tag to load JavaScript code from another web site. That code could be harmless but it could also contain something dangerous, like malware. What CSP does is make it possible for a web site author, via HTTP headers, to specify what types of scripts can be loaded and from where. For developers who are setting a policy, it adds a layer of protection where even if they make a mistake it is likely to be mitigated by this additional layer of policy.

Clickjacking attacks are where someone embeds a page into a transparent iframe and “steals” user clicks to activate something dangerous. One particular attack allows a browser to be turned into a remote surveillance device. CSP includes the ability for a page to tell the browser that it never wants to be ever included in an iframe.

And last is the ability for a web site to tell the browser that it never wants resources from that page to be loaded over unencrypted HTTP. Banking and other commerce sites will find this particularly useful.

CSP is very powerful and flexible, allowing you to specify whether or not you want to load different kinds of media, different kinds of script methods, css, can be used to set up loading only from specific other hosts and a large number of other things. It’s meant to be very easy to set up for simple cases but will scale up to pretty complex infrastructure where different resources might be spread out over a large number of machines.

Here are four examples that show common use cases. Each of these examples is a header that’s delivered as a header over HTTP and it affects how the page is rendered.

A site wants all of its content to come from its own domain:

X-Content-Security-Policy: allow 'self'

Example 2: An auction site wants to be able to load images from anywhere, plugin content from a list of trusted media providers and a CDN network and scripts only from its server hosting sanitized JavaScript:

X-Content-Security-Policy: allow 'self'; img-src *; 
                           object-src media1.com media2.com *.cdn.com; 
                           script-src trustedscripts.example.com

Example 3: Server administrators want to deny all third-party scripts for the site, and a given project group also wants to disallow media from other sites (header provided by sysadmins and header provided by project group are both present):

X-Content-Security-Policy: allow *; script-src 'self'
X-Content-Security-Policy: allow *; script-src 'self'; media-src 'self';

Example 4: An online payments site wants to ensure that all of the content in its page is loaded over SSL to prevent attackers from eavesdropping on requests for insecure content:

X-Content-Security-Policy: allow https://*:443

The implementation isn’t quite complete yet, but it’s pretty close. There’s more information on the demo page for CSP, read the overview or read the spec itself.


5 comments

  1. jaredzusmc

    Thanks for this info. Really like the definitions of basic attacks. I’m used to the terms, but not all people are.
    Not trying to “attack” just wanting to see the escape parameters here:
    Google
    Google

    Thanks again for the inside scoop,

    J.

    October 6th, 2009 at 14:51

  2. jaredzusmc

    EXCELLENT… the simple Google URL worked but the embedded javascript obviously did not.

    I’m sure this is just an escape mechanism and not the actual CSP.

    J.

    October 6th, 2009 at 14:53

  3. Rayj

    I just dont fucking understand why I block this damn pop up from mozilla and it still keeps coming up with crap i will never buy. i would apprecitate it if you guys drop this crap !!!!!!!!!!i am so pissed off about these damn pop up for shit that no one wants just to make you guys more money.

    October 8th, 2009 at 16:40

  4. […] raw graphics through canvas and WebGL, native video, advanced XHR capabilities mixed with new security tools and network […]

    November 8th, 2009 at 21:51

  5. […] 在过去五年中很明显改变的一件事情是在众多现代浏览器──Firefox、Safari、Opera和Chrome──同世界最流行浏览器──IE之间各个方面产生的巨大差异。现代浏览器是为了未来那些互联网应用构建──超级快速的JavaScript,现代CSS,HTML5,支持多样的互联网应用标准,支持可下载字体,支持离线应用,通过canvas 和 WebGL支持原生图像处理,原生视频支持,高级XHR支持兼具高级安全工具和网络能力。 […]

    November 9th, 2009 at 04:32

Comments are closed for this article.