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.
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:
|CMS||CSP by default||3rd Party Plugins Available?||Notes|
|WordPress||No||Yes||The WordPress ” Content Security Policy“|
plugin was available, but did not set the
CSP header for any administration pages.
Instead the CSP is only set on the ‘user side’.
If an attacker attempts to exploit XSS
vulnerabilities in the administration panel
then exploitation will succeed.
|Drupal||No||Yes||Numerous 3rd party plugins are available |
intended to implement CSP support.
Of the 3rd party plugins analysed the
SecKit plugin was found to have richest
set of functionality of any of the 3rd party
|Joomla!||No||No||I was unable to find any 3rd party |
plugins that implemented CSP.
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.
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:
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