Content Security Policy (CSP) is an effective, browser-based deterrent against cross-site scripting attacks. Despite this, the vast majority of websites do not deploy the standard, and the majority of those that do, deploy it improperly.
The goal of CSP is to mitigate content injection attacks against web applications directly within the browser. It does so by sending the policy via a security header sent by the server to the client which must then enforce it. It allows developers or administrators to define the origins from which different classes of content can be included into a document.
The policy is supported by the current versions of almost all major browsers, including some mobile browsers, though it’s only partially supported by Internet Explorer. Yet, CSP is deployed on just one percent of sites in the Alexa Top 100 and most installations fail to leverage its full defensive power.
If CSP is a freely available defense against XSS attacks, then why is it so scantly distributed and why is XSS still among the most widely used data exfiltration attacks? The reality, according to a trio of researchers from the Northeastern University department of computer science, is that proper CSP implementation is difficult to achieve without breaking website functionality.
Furthermore, there is no easy or automated way to customize CSP builds in order to match the unique needs of each individual website. Advertisements, in particular, seem to present a significant road block to CSP adoption.
In a research paper titled, “Why is CSP Failing? Trends and Challenges in CSP Adoption“, Michael Weissbacher, Tobias Lauinger, and William Robertson, examined CSP deployment in the Alexa top one million sites during a 16-month period. They found that the protocol lags behind other, more narrowly focused, security headers such as X-XSS and x-frame-options and browser-based security tools such as AdBlock, AdBlock Plus, GrooveShare Downloader, ScriptSafe, and DoNotTrackMe. In the rare cases where CSP is present, it’s often misconfigured to the point where its purported purpose, namely to protect against content injection and data exfiltration attacks, are negated.
The researchers determined that site architectural features can influence whether it’s possible to deploy CSP without making structural changes to the site in question.
For example, they found that Twitter has mostly internal resources built into its site:
“Multimedia content included in tweets, for instance, was loaded from internal subdomains with constant names,” they write. “Such an architecture makes it relatively convenient to deploy CSP without major changes. Indeed, Twitter used CSP in some subdirectories and subdomains.”
On the other hand, sites such as GitHub, Amazon, and Facebook have many features originating from external content distribution networks with dynamically named subdomains.
“A cleaner approach would be to use static domain names at the web application layer and address load balancing transparently at lower layers, as appears to be done by Twitter.”
Weissbacher explained the primary reason for CSP’s low level of adoption is that many sites would have to change their structure, which – in turn – could entail expensive changes to legacy code. He went on to say that CSP is the best available solution to XSS – a method of attack that the Open Web Application Security Project considered the third most prevalent risk to web application security.
“I looked into CSP deployments because it is effective against XSS and could solve lots of problems with web security,” Weissbacher explained to Threatpost. “So I was surprised to find that only few websites used it, and those who did, didn’t use it fully, marginalizing the benefits. I think it would help the web at large if more websites invest the effort to implement CSP.”
Weissbacher, Lauinger, and Robertson discussed CSP implementation with three security engineers for three separate sites (two were in the Alexa Top 200, and one in the Top 5,000). The engineers had three primary complaints:
One problem, they said, is that CSP blocks the execution of inline javascript. This is problematic because most websites and websites developers prefer not to remove inline scripts. Secondly, the protocol – particularly the way it interacts with certain browser bugs – breaks functionality, and the consensus was that a secure but unusable website is more harmful than the occasional XSS. Lastly, and on a similar note, the enforcement of CSP rules frequently breaks important extensions.
These, the researchers and the engineers determined, are solvable problems. They say ads should be integrated into sandboxed iframes rather than embedded directly onto sites, which would eliminate the need for building long whitelists of trusted ad networks. Broader web applications and framweorks should just go ahead and adopt CSP in order to limit the amount of customization required by individual websites (phpMyAdmin and OwnCloud have adopted CSP and Django can be configured with CSP). Also, browsers just shouldn’t enforce CSP on extensions. CSP, they said, is not an adequate tool for websites to block undesirable extensions and it shouldn’t be used as such.
“CSP clearly holds great promise as a web security standard, but we can only conclude that it is difficult for most sites to deploy it to its full potential in its current form,” the researchers concluded. “It is our hope that the improvements we suggest here, as well as up- coming features of the 1.1 draft, will allow site operators and developers to make effective use of content security policies and result in a safer web ecosystem.”
