Defeating Cross-site Scripting with Content Security Policy

If you have been following Neohapsis’ @helloarbit or @coffeetocode on Twitter, you have probably seen us tweeting quite a bit about Content Security Policy.  Content Security Policy is an HTTP header that allows you, the developer or security engineer, to define where web applications can or can not load content from.   By defining a strict Content Security policy, the deveopers of web applications can completely almost completely mitigate cross-site scripting and other attacks.

CSP functions by allowing a web application to declare the source of where it expects to load scripts, allowing the client to detect and block malicious scripts injected into the application by an attacker.

Another way to think about content-security policy is as a source whitelist. Typically when an end user makes a request for a web page, the browser trusts output that the server is delivering. CSP however limits this trust model by sending Content-Security-Policy header that allows the application to specify a whitelist of trusted (expected) sources. When the browser receives this header, it will only render or execute resources from those sources.

In the event that an attacker does have the ability to inject malicious content that is reflected back against the user, the script will not match the source whitelist, and the script will not be executed.

Traditional mechanisms to mitigate cross-site scripting are to HTML encode or escape output that is reflected back to a user as well as perform rigorous input validation. However due to the complexity of encoding and validation, cross-site scripting may crop up in your website.  Think of CSP as your insurance policy in the event something malicious sneaks through your input validation and output encoding strategies.

Although we at Neohapsis Labs have been researching Content Security Policy for a while, we found that it’s a complicated technology that has plenty of intricacies.  After realizing that many users may run into the same issues and confusion we did, we decided to launch to help educate developers and security engineers on how to use CSP as well as a way to validate your own complex policies.

CSP Playground allows you to see example code and practices that are likely to break when applying CSP policies.  You can toggle custom policies and watch in real-time how they affect the playground web application.  We also provide some sample approaches on how to modify your code so that it will play nicely with CSP.  After you have had time to tinker around, you can use the CSP Validator to build out your own CSP policy and ensure that it is in compliance with the CSP 1.1 specification.

The best way to learn CSP is by experimenting with it.  We  at Neohapsis Labs have put together site just for those reasons and suggest you check out the site to learn more about it.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s