Content Security Policy has been in development for quite some time.. The basic idea behind the standard is to give webmasters a tool at hand to whitelist JavaScript, and other objects and files, that may be executed on the site. This implementation blocks all JavaScript code that is executed on the site and not in the list of allowed sites, which means that attackers cannot exploit possible XSS vulnerabilities on the website or server.

A browser supporting CSP ignores code that is not in the whitelist. Browsers who do not support CSP ignore the policy.

Content Security Protection for Users

CSP is currently only supported by Firefox 4, Thunderbird 3.3 and SeaMonkey 2.1. You can test the functionality by visiting this test page.

Twitter recently announced that they have added CSP to their mobile version, accessible under mobile.twitter.com. Users who use one of the aforementioned browsers are protected from XSS attacks on that website.

The engineers on Twitter removed all JavaSCript from code and implemented the CSP header. They then restricted the header to Firefox 4 users and created a rule set to allow JavaScript from their assets. This included the content deliver network used to deliver stylesheets and user profiles.

Unexpected issues were encountered by the developers. They noticed for instance that some Firefox add-ons were inserting JavaScript on page load, which triggered a threat report. The Twitter engineers noticed furthermore that some ISPs inserted JavaScript code or altered image tags for caching reasons.

They managed to resolve those problems by mandating SSL for all Firefox 4 users who access the mobile Twitter web site.

A test with Firebug shows that the mobile version of Twitter is indeed using the policy on site. Please note that Twitter makes a user agent check and is very restrictive about it. Firefox 5 or Firefox 6 users won’t get the policy currently.

Content Security Protection for Webmasters

Webmasters may have some work at hand to add support for CSP to their website. JavaScript code that is directly embedded in documents will not be executed anymore, which has several implications. Webmasters need to move the code to external JavaScript files.

Policies are specified with the X-Content-Security-Policy header. The header X-Content-Security-Policy: allow ‘self’ *.ghacks.net for instance allows JavaScript to be loaded from ghacks.net and all subdomains of ghacks.net.

The using CSP guide on Mozilla offers additional examples on how to set the right headers.

Browsers that do not support CSP ignore the header.

CSP offers two additional forms of protection. It mitigates clickjacking attacks. Clickjacking refers to directing a user’s mouse click to a target on another site. This is often done by using transparent frames on the original website.

Content Security Policy can also be used to mitigate packet sniffing attacks, as it allows the webmaster to specific protocols that are allowed to be used. It is for instance possible to force HTTPS only connections.

The CSP Policy directives are accessible here on Mozilla.

Next to the already mentioned options are parameters to specific hosts where images, media files, objects or fonts may be loaded from.

Plugins are available for WordPress and Drupal that add the policy to supported websites automatically when activated.

Bookmarklet

A bookmarklet has been created by Brandon Sterne to aid webmasters in defining the correct header. It basically scans the page for JavaScript and displays a suggested policy.

Issues and Concerns

The biggest problem currently is that CSP is only supported by Firefox 4. Not by Internet Explorer, Chrome, Opera or Safari. But even if it would be supported by all browsers, it would still depend on webmasters to implement the headers on their websites.

A push in the right direction could come from Twitter, if the decision is made to role out the CSP header to the main Twitter web site as well.

Many popular guestbook and forum programs allow users to submit posts with html and javascript embedded in them. If for example I was logged in as “john” and read a message by “joe” that contained malicious JavaScript in it, then it may be possible for “joe” to hijack my session just by reading his bulletin board post. Further details on how attacks like this are accomplished via “cookie theft” are explained in detail below.

Source: “The Cross Site Scripting FAQ”. Click link to read the whole faq.

Update: Users who are looking for protection against Cross Site Scripting attacks may want to check out the excellent NoScript add-on for the Firefox web browser. XX protection is automatically enabled after installation. The extension for Firefox blocks untrusted websites from injecting scripts into trusted websites, which is an excellent way of protecting users from XSS attacks.

Additional information about Cross Site Scripting are available on Wikipedia. The external links section on the site is especially useful for researchers and security interested users.