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.

A cross site scripting vulnerability was recently discovered by a security researcher on the LastPass.com website. The potential to exploit the vulnerability was limited, as it required a specifically prepared website and a user who was logged into LastPass.

The developers stated on the official LastPass blog that the logs did not indicate that the vulnerability was successfully exploited, other than by the security researcher who discovered it.

The vulnerability has been fixed and, as a consequence, security has been improved on the Last Pass website. The developers list four areas of improvements:

• Implementation of HSTS which basically forces supported web browsers (Chrome and Firefox 4 currently) to stay “on secure SSL web requests for the lastpass.com domain.”
• Increased input filtering and stateful inspection
• Implementation of X-Frame-Options which makes it impossible to embed Last Pass pages via iframes or frames.
• Implementation of “something very similar to Content Security Policy” which allows the LastPass admins to specify how content interacts on their website.

The LastPass blog offers links to several of the concepts and technologies that have been added or implemented as a reaction to the discovered vulnerability.

LastPass users who would like to take a look at the original article can do so here. It details the security researcher’s methodology and is a good read for security interested computer users.

Javascript will be temporarily disabled during login and the data is send right to the website that you want to login to. The Domain that you are currently on and that you want to login to are compared to ensure that you are indeed at the right website. A mismatch would result in a popup warning.

Some websites use Javascript for their login routine and Secure Login offers a list that contains site that are exceptions. Just add the website as an exception if you can’t login using the Secure Login extension.

Username and Password fields are colored orange and a sound can be played (optional) to let you know that you reached a page with a login form. The shortcust ALT + N would send the login details to the server without filling out the form. this is a very convenient way to login.

Secure Login offers additional protection against cross site scripting attacks by protecting from any Javascript code during logon. This is an optional setting that can be enabled in the extension’s options.

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.