Implementing Content Security Policy on your site.
post by: mosesrenegade
I’ve always told my students that if they where going to be doing any type of web application penetration testing, they should consider running their own web servers. I choose crazily enough to run WordPress. I say this because I realize that I run a high risk of exposure running WordPress. I’ll be writing about this in the future, mostly because I am actively still teaching SANS 642 and SANS 542.
This web server is a testament to this because of the mental gymnastics one has to go through while running a server that is less than perfect from a security point of view. Pragmatism has its costs. Some costs include those of the CSP, or better known as Content Security Policy. I’ll be honest, CSP is rather a gigantic pain the butt to implement if you are not willing to put in the legwork. It can be something that you can reward yourself with, but as you will with this post, its less than perfect.
I am currently using popular tools, NGINX, WordPress, New Relic, Google Analytics, Google Ad Words, Gravatar, Facebook Like, and more. The CSP has to take all of this into account.
Current CSP Header
If you consider that the headers are being delivered to you already, nothing I am revealing here is secret.
[x_code]script-src 'self' 'unsafe-inline' 'unsafe-eval' https://js-agent.newrelic.com https://*.nr-data.net https://*.wp.com https://*.gravatar.com https://*.wp.com https://pagead2.googlesyndication.com https://ssl.google-analytics.com https://connect.facebook.net https://www.google-analytics.com https://cdnjs.cloudflare.com https://ajax.cloudflare.com;[/x_code]
The next directive is ‘img-src’ which tells the browser where it is safe to load images from. WordPress for some reason uses *.w.org and *.wp.com for shortening of links.
[x_code]img-src 'self' data: https://wordpress.org https://*.w.org https://*.gravatar.com https://*.wp.com https://ssl.google-analytics.com https://s-static.ak.facebook.com https://www.google-analytics.com;[/x_code]
Style-src is for our Style Sheets, nothing really to note here.
[x_code]style-src 'self' 'unsafe-inline' https://*.wp.com https://*.gravatar.com https://fonts.googleapis.com;[/x_code]
Font Source is for our web fonts on this site. You may find adobe in here as well from time to time.
[x_code]font-src 'self' data: https://fonts.gstatic.com https://themes.googleusercontent.com;[/x_code]
Frame-src lets us know where it safe to load frames from, although only the sites such as Facebook, double-click and *.wp.com are used here.
[x_code]frame-src 'self' https://*.wp.com https://*.doubleclick.net https://www.facebook.com https://s-static.ak.facebook.com;[/x_code]
Object-src is for objects, of which there are no objects here to mention.
One of the bigger challenges that you may find is that your experience and your user’s experience may be completely and utterly different. Because of that you would have to capture errors that the user is seeing which could be quite difficult.Someone who is part of the twitter security team, was kind enough to reach out to me on twitter (@ndm).
I’m not so sure he has to worry about his three-letter twitter handle now since he works for twitter, but he was nice enough to write to me and give me some links. Update: Works now at Github.
He mentioned he used two items, caspr which is a Google Chrome Plugin and Report-URI.io. Both of which I found to be amazing tools. Report-URI.io lets you send in error events right to a specific system for later analysis.
Why is this valuable? It would seem that every day I am finding new areas of the system I need to white list that i did not take into account.
Github gists has been updated and twitter has been updated to include twitter short codes.
Links of Note
As always there are a few people who helped here tons, and a bunch of links to also help out.
Current Content Security Policy