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.

Adobe published a temporary workaround to protect the computer system against this form of attack that users should apply until the release of a patch that would fix the critical issue.

To apply the workaround users should visit the Flash Player’s Settings Manager by following the link. There they should click on the Always Deny button which would prevent any website from accessing the microphone and webcam settings.

The new setting has to be confirmed in the popup that appears automatically after clicking on the Always deny button. The patch is said to be available before the end of October.