CSP: Thwarting cross-site scripting and click-jacking attacks

by Daniel Bachfeld

Content Security Policies are designed to prevent cross-site scripting and other attack types. Firefox 4 is the first browser to support this new concept.

Cross-site scripting (XSS) has become the plague of the internet, and even the banks haven't managed fully to tackle this problem on their web sites. However, XSS attacks on browsers could soon be a thing of the past, at least for Firefox users: the Mozilla Foundation's latest version 4 of Firefox supports the concept of Content Security Policy (CSP). This allows web administrators to tell browsers which domains to accept as trusted sources of JavaScript code by sending the special X-Content-Security-Policy HTTP header.

When CSP is enabled, JavaScript code embedded in HTML documents is no longer executed by default. Whether the code was already included in the original HTML document or injected during an attack will make no difference – the code will simply be ignored by the browser. CSP will consequently also thwart typical XSS attacks that use specially crafted URLs containing embedded JavaScript.

As an alternative, however, the HTML document to be rendered will be able to retrieve JavaScript code from permitted sources in the form of js files. For example, including X-Content-Security-Policy: allow self will restrict the browser to accepting code that is provided by one's own server. Admins can also include a list of additional permitted domains in the CSP header. Unfortunately, CSP also disables such JavaScript-controlled HTML events as onclick.

Those who wish to implement server-side CSP will, therefore, need to do a considerable amount of web page restructuring. Microblogging service Twitter has already gained early experience with the new option on its mobile.twitter.com domain. When implementing the concept, the most involved step was reportedly separating the HTML code from the JavaScript code. Embedded (inline) JavaScript code had to be moved to separate files and then re-loaded via script tags. JavaScript functions linked to HTML events must first be added to the list of available events via the addEventListener function.

Twitter's policy defines several servers from which browsers are permitted to load content.

When adapting and testing their code, the Twitter developers found that, because they try to write code into HTML documents, the CSP alerts were triggered by several Firefox plug-ins. The developers were surprised to find that many ISPs appear to inject JavaScript into HTML documents on page load, for example in order to point image tags to their caching servers. The developers also had to adapt several JavaScript libraries. On the whole, the Twitter developers said that they are happy with the introduction of CSP on mobile.twitter.com, and that they eventually plan to introduce the protective measure across their entire platform.

Multi-protection

However, JavaScript can not only be embedded in HTML pages, it can sometimes also hide in specially crafted images and other objects. For instance, Internet Explorer (IE) used to use MIME sniffing to detect, and then execute, code contained in bitmaps. CSP is consequently not limited to the loading of script code but can also be extended to include images, style sheets, frames, fonts and other objects. Conveniently, this allows CSP to partially solve the click-jacking problem.

By transmitting the frame-ancestor header parameter, a web server signals to the browser that a loaded page mustn't be opened in an iframe. This prevents click-jackers from including transparent iframes that trick users into clicking on invisible elements. Unlike the X-Frame-Options (XFO) header, an anti-click-jacking solution preferred by Microsoft, CSP allows a domain list to be included, which offers considerably more flexibility. The new header can also determine whether a browser is to load further content via HTTP or via HTTPS.

However, CSP only offers limited protection against persistent XSS. Although attackers can no longer simply inject JavaScript code into HTML pages via such elements as comments, CSP ceases to be effective when an attacker does, in some way, manage to inject malicious code into a database or other data containing legitimate JavaScript code. Fortunately, such cases of persistent XSS are relatively rare. Against cross-site request forgery (CSRF) attacks, on the other hand, CSP offers no protection at all. However, web admins can reportedly render such attacks ineffective by sending the Origin header.

Backward

CSP is said to be fully backward compatible. If a web site doesn't send a CSP header, Firefox will simply fall back on the Same-Origin Policy. Browsers that don't support CSP will simply ignore the header. The Mozilla Foundation's Brendan Sterne, who is the master-mind behind CSP, has set up a test page that demonstrates the use of the various CSP parameters and options. CSP also allows admins to define a URI to which to send a message in case of a policy violation. This not only helps admins discover attacks, it also assists them with troubleshooting when making the switch.

The CSP demo allows developers to establish how the restrictions will affect the loading of objects.

In addition to Firefox, Thunderbird 3.3 and SeaMonkey 2.1 are soon planned to support CSP on the client side. Now, the only thing missing is that further browsers and web server operators adopt the new concept. Most browser developers previously implemented their own anti-XSS functions and counted on the X-Frame-Options header to prevent click-jacking attacks. However, this strategy found no acceptance with web site operators. One can only hope that CSP will be better received. Help with adapting, for instance, a custom content management system is available via plug-ins such as those for WordPress, Drupal and the Django web framework. (dab)