After years of discussion and waiting, Mozilla has finally added Content Security Policy 1.0, a defense against some common attacks such as XSS, to its Firefox browser. CSP already has been implemented in Google Chrome and Internet Explorer and there was a limited implementation of it in Firefox previously, beginning in 2011, but this is the first time the approved 1.0 specification has been implemented in Firefox.

CSP is a specification designed to help limit the sources of content that can run on a given Web site. One of the ways that attackers compromise users’ machines  by inserting malicious scripts on a target Web page. Sites today often pull content from multiple different sources, including social networking sites, ad networks and other sites, and it’s difficult for site owners to validate whether each of those pieces of content is safe. Cross-site scripting attacks take advantage of this weakness.

CSP is meant to prevent XSS and other similar attacks from succeeding by restricting the sources of content on a given page.

“In general, CSP allows web developers greater control over their content, helping mitigate several security problems. One major benefit of CSP is that, by default, it prevents inline scripts from executing. This greatly helps mitigate the threat of XSS (Cross Site Scripting) or other forms of script injection,” Ian Melven of Mozilla wrote.

“The concept of CSP gained traction fairly rapidly, with Chrome shipping their first implementation, using the X-Webkit-CSP header, in August 2011. After much discussion among security and web experts, in November 2011 a working draft of a W3C specification for Content Security Policy 1.0 was published. The syntax specified by the working draft was quite different from the syntax used by the initial Firefox implementation, as concepts had over time evolved and been refined.”

One of the changes in the new implementation of CSP in Firefox is that it no longer uses the older, un-prefixed header. Now, CSP uses the Content-Security-Policy header rather than the X-Content-Security-Policy header.

“This is great, because we no longer have the situation where a site has to send multiple CSP headers (with different syntax !) to have its policy enforced in CSP-supporting browsers. The same Content-Security-Policy header will work for Firefox, Chrome, IE 10 (sandbox only) and any other browsers that implement the spec. If for some reason a site sends both the X-Content-Security-Policy header and the Content-Security-Policy header, the prefixed header will be ignored and only the policy from the unprefixed header will be applied,” Melven said.

One other major change in the CSP 1.0 implementation is that it now blocks inline styles in Firefox. This helps prevent certain kinds of attacks that use the injection of some site elements into target sites.

“This was a later addition to the CSP spec. It aims to prevent attacks via injecting <style> elements or another HTML element with a style attribute. These attacks can be carried out even when executing script is not allowed. Some potential attacks include using CSS selectors to exfiltrate data from the page and using attributes to overlay one element on top of another, leading to a possible phishing attack,” Melven said.

Categories: Vulnerabilities, Web Security

Comments (4)

  1. Matheod

    Why is it to browser to implement security ?
    Now website will have no reason to securise and they will reject the fault to navigator who doesn’t have XSS protection. When people will report XSS vulnerability, devs will tell them : “Hey, I don’t see the problem, I don’t see your alert popup.”, when we will tell them : yes but it’s because your browser have security, try with an old browser they will laugh.

  2. Josh

    > “Now website will have no reason to securise and they will reject the fault to navigator who doesn’t have XSS protection”

    CSP is a security feature browsers support, but that websites implement. Depending on the website it may require a massive amount of re-engineering to support it. Basically the way it works is that script and content get separated into separate files and the website uses headers to say to the browser “Don’t run any script that is embedded in the content, and don’t load any script files from anywhere but these domains”. There are a lot of other tuning options, but that’s the gist of it. The browser needs to support CSP so that the website can tell it how to treat script

    The implications of CSP are the opposite of what you propose – rather than a site being able to ignore security they must explicitly implement it.

    • matheod

      Oh sorry, I misunderstood what it was about.
      Forget what I said, I thought it was just an improvement of the XSS filter (which prevent data from GET/POST to be executed as javascript).

Comments are closed.