Implementing CSP on a WordPress blog

Written on 16 February 2018, 06:34pm

Tagged with: , , ,

In the previous post I briefly described the CSP concept, along with other nice security features like SRI or CORS.
I am trying to implement the concept here, and I am describing the steps I take along the way. I am using securityheaders.io to scan the website and validate the results; and this website is hosted on Cloudflare over HTTPS.

The first impression is – WordPress doesn’t make it easy to have a proper Content Security Policy. But let’s dig into it!

Session 1

The quick wins
– Edit the .htaccess file to add the quick and dirty security headers:
X-Frame-Options, X-XSS-Protection, X-Content-Type-Options, Referrer-Policy
– Strict-Transport-Security was already enabled via CloudFlare since October 2017.

Just do it!
– add the CSP directive in the .htaccess file. Start with default-src, whitelist all the usual suspects (Twitter, Google Analytics, Cloudflare, Flickr, etc)
– at this stage, some problems are evident, but at least securityheaders.io already reports an A+ score
– the basic functionality is still there, so progressive enhancement FTW

Session 2

Now refine and iterate
– check the results on result-uri.comΒ report-uri.com, or, even easier, using DevTools
– disable the syntax highlighter and the image highlighter plugins, will find something CSP-friendly later
– whitelist even more in CSP (youtube.com, among others)
– disable the report-uri, the errors are building up quickly
– finding the main problem: inline content

Keep calm and avoid inline content
– I don’t want to whitelist ‘data’, ‘inline’ and ‘eval’, which would defeat half of the purpose, so keep iterating
– as I said, WordPress makes it really difficult by inlining several things (WP emoji being one of them)
Unless you really know your web site inside and out, I would caution you to use CSP together with WordPress at the moment. (https://walterebert.com/blog/using-csp-wordpress/) Turns out, I really want to know
– removing inline content (https://www.denisbouquet.com/remove-wordpress-emoji-code/), or trying to move it inside files
– Akismet, you too? πŸ™
– OK, it’s not only WordPress embedding inline content, it’s also Twitter (well, technically it was me, because I wanted my Twitter feed on the blog)
– hey, the WordPress Admin is impacted too, cannot upload images!!
– {angry+emoji} (I disabled the WP emoji above, remember?)

Session 3

– remember WP-Admin and CSP? Yeah, forget about that {sad-emoji}
– Twitter timeline and follow button embed without inline scripts – done https://publish.twitter.com/
Aksimet, really? why would you inline that?

(function(){if(window===window.parent) {document.getElementById('_wp_unfiltered_html_comment_disabled').name= '_wp_unfiltered_html_comment';}})();

– Nevermind, it was not Akismet. Just WordPress
– it looks like the admin-ajax.php inline call was trigerred by my WordPress theme for the ‘like’ system. I removed it and now the red heart is beating. Not functional, but way cooler than before B-)

End of the session 3. Kids, be very careful with CSP!

Session 4

– Who needs a syntax highlighter WordPress plugin when you have prismjs.com? Doesn’t support ColdFusion language, but I can always contribute the syntax file myself. I have to replace the code in all the previous posts, but I can automate that and the result will be semantically correct.
– Who needs to click images to make them bigger? HighSlide was nice, but it did not bring too much value.
– Ok, so 98% of cases I don’t need the images to be clickable. I can live with the rest of 2%

End of session 4. CSP enabled, securityheaders.io still indicate A+, I load no inline and eval content. Still allow ‘data’ in CSP, not ideal.
Next steps:
– some posts to be updated for the syntax highlighting and clickable images.
– add SRI to some of the JS libraries
– understand why CloudFlare automatically loads Google Analytics and try to get around their data: embedding

Session 5

– I will always write semantic code in WordPress.
– I will always write semantic code in WordPress.
– I will always write semantic code in WordPress.
– There. That’s 2 hours spent replacing custom [code] tags with <code> tags.
– Most of the images should also be ok, in case a small minority of them is still clickable it will simply open the full-size image in the same tab.
– Why does CloudFlare load Google Analytics?
– D’uh, turns out I had enabled it a few years ago. Along with two other CloudFlare apps (Earth Hour and Net Neutrality). And that was the reason why CloudFlare was inlining scripts. The explanation was in front of my eyes all the time:

If you use certain Cloudflare features, you will need to allow inline scripts in your policy. We include scripts on your domain and add some inline code when you enable Rocket Loader, Cloudflare Apps, or ScrapeShield.
If you do use any of these features, you will need to add the following to your Content Security Policy:
script-src 'self' 'unsafe-inline'
January 31, 2018: What is Content Security Policy (CSP), and how can I use it with Cloudflare?

– Next stop: some images inlined as data: elements:

Refused to load the image 'data:image/svg+xml;charset=utf-8,%3Csvg%20xmlns%3D%22http%3A%2F%2Fwww.w3.org%2F2000%2Fsvg%22%20width....' 
because it violates the following Content Security Policy directive ... 

– This time it was Twitter. So either I accept ‘data:’ in the CSP for images, or I turn off the Twitter timeline… {thinking_emoji} I asked @TwitterDev if there is any workaround
– Remaining steps: rewrite the CSP to make it more restrictive (I started by putting everything inside default-src) and use SRI for a few remote scripts (jQuery maybe?)

End of session 5.

Session 6

– SRI done thanks to SRI Hash Generator:


<script type='text/javascript' src="https://ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.js" integrity="sha384-aBL3Lzi6c9LNDGvpHkZrrm3ZVsIwohDD7CDozL0pk8FwCrfmV7H9w8j3L7ikEv6h" crossorigin="anonymous">

– Made the CSP header more restrictive and very verbose (newlines added for readability):


img-src data: https://colorblindprogramming.com https://*.twitter.com https://*.twimg.com https://*.flickr.com https://*.staticflickr.com https://*.gravatar.com https://*.yahoo.com; 
script-src https://colorblindprogramming.com https://ajax.googleapis.com https://*.gstatic.com https://*.youtube.com https://*.yahoo.com https://*.twitter.com https://*.flickr.com https://*.twimg.com; 
style-src 'unsafe-inline' https://colorblindprogramming.com https://fonts.googleapis.com https://platform.twitter.com https://ton.twimg.com https://*.youtube.com; 
frame-src https://*.youtube.com https://*.twitter.com; 
report-uri https://colorbind.report-uri.com/r/d/csp/enforce;
The final CSP rules

Testing

A quick way to test the SRI is to alter the hash in the integrity attribute. As soon as you do this, the browser will report the error:

To test the CSP, I connected to the database and manually added some Javascript in a comment:

With the CSP allowing script-src 'unsafe-inline', the code executed:

With the CSP not allowing script-src 'unsafe-inline', the code did not execute and the browser reported the problem:

Next step is to keep monitoring report-uri.com for the CSP violations.

The takeaways

– use the DevTools to validate your CSP rules
– start with validate-only to ‘test in production’
– avoid inline content at all costs
– think about all the plugins that you use: are they really needed?
– make sure you create WordPress content by writing semantically correct code

That’s it! 6 different sessions and about 10 hours allocated to this little project, but I’m happy with the results πŸ™‚

Comments (9)

  1. Dorin Moise — February 18, 2018 at 10:50

    Just testing CSP πŸ™‚ Below it’s a

    <script>alert(1);</script>

    CSP should prevent displaying the alert:
    ||

    And it does

    Reply

  2. Robin — February 2, 2019 at 19:50

    Interesting article, I’ll be passing it on to people to show it can be done.

    On session 2, it is report-uri.com, not result-uri.com.

    Reply

  3. Khan — January 30, 2020 at 20:15

    Amazing. Thanks for writing such a detailed article. I had to read and scour the web for an hour or two just to understand exactly what CSP was trying to secure and how. Lots of advice is simply to whitelist ‘inline’, probably without too much though being put into the reasoning behind.

    That being said, I do need my plugins and I really do not feel like removing/re-writing every single inline JS in my Woocommerce site :/ So I think I’ll just live with a lack of CSP and more importantly an A+ score… πŸ™‚

    Reply

  4. JimmehBoy — February 14, 2020 at 08:41

    Hello! After many hours of reading what I could find on the issues surrounding WordPress and adherence to CSP, I’ve read some compelling reasons why allowing unsafe-inline really may be better left in place, specifically for php-based platforms like WordPress

    @jadedragon makes a good argument for it https://core.trac.wordpress.org/ticket/39941

    TLDR version of that: ” By templating JS via PHP wordpress does and has always provided a means of JS injection. Because templating === injection. This is why WordPress has such a bad reputation for XSS exploits. And you’re providing a means to make sure all the templated JS has valid nonces. That means that if someone manages to insert their own code into the templated JS by exploiting poorly formed PHP… the XSS JS code will be in a script tag that has a valid nonce. You’re actually removing the need for the attacker to guess the nonce by adding it for them.”

    Unfortunate!

    Reply

    • Dorin Moise — February 14, 2020 at 11:11

      Thanks Jimmeh. The goal is to avoid all the inline scripts, and this is what I aimed for.
      Cheers!

      Reply

  5. Rich Knecht — May 1, 2020 at 23:48

    Being someone who knows good and well how to secure Apache – It’s no wonder there are so many security issues with WordPress. Getting a good CSP is almost impossible because of all the poor coding practices in WordPress, Themes, plugins. It’s a hackers feeding frenzy. I have yet to get a CSP that will cover everything wrong with WordPress sites. You only choice is shut off CSP – even worse choice. Developers need to get grip on how they are coding for WordPress!

    Reply

Leave a response