Content Security Policies and Popular CMS Systems

The problem

Recently I have been looking into Content Security Policy (CSP) and how widely it has been deployed. If you are unfamiliar with CSP, then a very good explanation can be found here.

Basically, CSP provides a way to protect against Cross Site Scripting (XSS) and similar content injection attacks by defining exactly what should and what shouldn’t be allowed to be executed from a website. For example; take a web application that contains a ‘Stored XSS’ (sometimes referred to as persistent) vulnerability. If an attacker exploits this vulnerability to inject arbitrary JavaScript into the page; the browser has no way of telling which scripts are legitimate and which are malicious – and will blindly execute everything (leading to the attacker’s code being executed in the context of your browser and thus session). CSP attempts to combat this class of vulnerability by saying to the browser “hey, this is what you should run. Anything else should be blocked”. This defensive functionality is achieved by defining a “Content Security Policy” header in the server’s response or within the page’s meta tag. Currently, due to the concept being relatively new, there are a number of headers supported by various browsers. These headers are listed below:

From the OWASP Content Security Policy page:

• Content-Security-Policy: Defined by W3C Specs as standard header
• X-Content-Security-Policy: Used by Firefox and Internet Explorer
• X-WebKit-CSP: Used by Chrome (and Safari)

Now you’re familiar with the CSP concept, I want to talk a little about how this feature affects popular CMS systems, such as WordPress, Drupal and Joomla. These CMS systems are widely used throughout the Internet due to their ease of use and extensibility through 3rd party plugins or modules. With this extensibility comes the increased risk of introducing new vulnerabilities to your website through insecure 3rd party plugins. In fact, XSS vulnerabilities in 3rd party plugins for CMS systems account for a large portion of vulnerabilities posted to vulnerability disclosure websites, such as Exploit-DB and theFull Disclosure mailing list in our experience.  This growing problem is where I believe CSP and other hardening techniques can really help with mitigating the impact of these vulnerabilities.

Popular CMS Support for CSP

With this in is mind, I decided to take a look at the most popular CMS systems and see which ones implement a Content Security Policy. The outcome? Well, the short answer is none. No CMS systems that I looked at currently implement CSP “as standard”. I did find that a number of 3rd party plugins were available that added this functionality, but I found none that fully worked. Below is a table of my findings:

 As summarised above, my research discovered that none of the 3 popular CMS systems I looked at included CSP functionality by default. I did find that a number of 3rd party plugins were available; however some lacked functionality or were broken, whilst others didn’t include CSP headers in all server responses (which undermines the point of CSP).

Until CSP is implemented within the Core of each CMS I would recommend that implementation is carried out at the server level (such as Apache headers) to ensure complete coverage and control of your Content Security Policy.

Turning that XSS into CSRF

It’s common knowledge that if your site suffers from XSS vulnerabilities, then protections such as Anti Cross Site Request Forgery (CSRF) tokens are pretty much null and void. Any client-side script running from the context of the site will have the ability to interact with web pages, and thus bypass such protections.

It should come as no surprise the same concept applies to CMS systems – an attacker can leverage an XSS vulnerability to bypass CSRF protection and make changes to your website, or perhaps add a ‘backdoor’ administrative account – all through injected JavaScript. As a Proof of Concept, I developed exploits for each of the CMS systems I looked at. These can be used as payloads to exploit existing XSS vulnerabilities found in the respective CMS systems, and will silently add a ‘backdoor administrator’ when the XSS is triggered by an admin. The CSRF protection bypass is achieved by loading the ‘add user’ page in an invisible iframe, filling out and submitting the form via JavaScript, thus bypassing the need to know the anti CSRF token.

The screenshot below shows the successful exploitation of the Joomla 1.6.0 XSS vulnerability (patched March 8, 2011) in the Core component of the Joomla CMS system using one of these payloads:

This is a little scary right? Well, it’s precisely what a Content Security Policy aims to protect (and does when configured correctly) to protect against, and the reason I feel that it should be seriously considered as a Defense in Depth strategy for any CMS administrator.

For example when attempting to exploit the same XSS vulnerability against Joomla with a correctly configured Content Security Policy, in Firefox we see:

Conclusions

What we learnt over the last 15 years or so, since XSS was first coined as a class of issue, is that trying to eradicate every instance is a hard task. As the number of legacy systems and web applications grows, any way to mitigate exploitation is likely a far more economical and scalable solution.  I’ve also shown that currently leading OSS CMS systems do not currently out of the box provide support CSP, if nothing else I hope this blog will act as a call to arms so all web software vendors will prioritize the implementation of native CSP support.

Published date:  16 April 2013

Written by:  Richard Warren