Content Security Policy (CSP) 1.1 is a specification used to control locations from where an application can load content as well as restrict insecure use of JavaScript. By blocking execution of inline JavaScript and dangerous methods such as eval(), setTimeout(), and others, exploitation of many cross-site scripting vulnerabilities can be prevented. It’s important to understand that this is in no way intended to be a first line of defense, and should never be used in place of proper input validation. However, in the event that an XSS vulnerability is introduced to an application, CSP may be able to provide a valuable layer of protection to users. CSP 1.1 is still a working draft, however is rapidly gaining traction and already in use by Google, Facebook, and Twitter. CSP in Ethical Hacking Many organizations rely on vulnerability assessments to provide a complete security review of their applications. In many cases, we (security professionals) are the only link between the w3c security communities and real world deployment of the technology. While raising an issue on an assessment because of a non-existent policy may not be appropriate, a note suggesting the application could benefit from it will often be well received. Inevitably, security professionals should also expect situations where CSP is used in attempt to mitigate or lower the risk of XSS vulnerabilities. Many application owners may be tempted to use CSP in place of a costly code change. At the time of this writing it is our strong opinion that CSP is not a strong enough control to mitigate risk for XSS or any arbitrary content loading vulnerability. Policy Delivery The policy is delivered to the user via a ‘Content-Security-Policy’ header, however CSP 1.1 contains an experimental meta tag delivery method. Below shows an example CSP header:
Content-Security-Policy: default-src 'self'; script-src 'self' cdn.example.com
This header also takes two other forms: X-Content-Security-Policy and X-WebKit-CSP. As browsers mature, ‘X-‘ prefixes and WebKit-CSP will be deprecated. For best possible support, it is recommended a policy be delivered with all three headers. Below shows an ideal response using all three variations:
Content-Security-Policy: default-src 'self'; script-src 'self' cdn.example.com X-Content-Security-Policy: default-src 'self'; script-src 'self' cdn.example.com X-WebKit-CSP: default-src 'self'; script-src 'self' cdn.example.com
Ethical hacking professionals should be aware that if CSP is in use by an application, but is not delivered on particular pages, this likely indicates an oversight by application developers and should be raised as an issue. CSP is effective on a per page basis, so it cannot prevent an XSS vulnerability if the header is not delivered on a vulnerable page.
Directives This article will not cover all CSP directives, but we will cover some new and important features which impact many applications. * default-src – this specifies a default location list for all other directives. The available options are ‘none’, ‘self’, ‘all’, hostnames, URIs, and schemes (ie https). This sets the default values for all other directives. It is recommended to set a restrictive default-src value, and then set more permissive values as needed for other directives. script-src – Controls where script can be loaded from. Two other parameters exist for this directive which can lift the default controls on JavaScript execution. unsafe-inline – Overrides the default CSP restriction of inline JavaScript and allows for scripts to be executed from within tags. unsafe-eval – Overrides the default restrictions of dangerous JavaScript functions such as eval(), Function, setTimeout(), and setInterval(). Use of unsafe-eval is not recommended, it is strongly advised that code rewritten in a safe manner is done before allowing dangerous functions. nonce-[random-value] – This is a recommended alternative to unsafe-inline. The nonce attribute should be supplied with a random value in your policy; the random value should be added as an attribute to tags. Below shows how inline JavaScript can be allowed using this method:
Content-Security-Policy: default-src 'self'; script-src 'nonce-Nc3n83cnSAd3wc3Sasdfn939hc3'
[…]
<script nonce="Nc3n83cnSAd3wc3Sasdfn939hc3">
alert("Allowed because nonce is valid.")
</script>
connect-src – Controls where Websockets, XMLHttpRequests, and Server-Sent Events can connect. This could mitigate a parameter tampering vulnerability if these functions are generated dynamically. reflected-xss (experimental) – This serves as a direct replacement for the X-XSS-Protection header.
<pre>reflected-xss allow
reflected-xss filter reflected-xss block Has the following equivalents:
<pre>X-XSS-Protection: 0
X-XSS-Protection: 1 X-XSS-Protection: 1; mode=block
Support * Chrome – As of version 25 Chrome includes full support for CSP as well as a mandatory subset of features imposed on extensions. Mobile versions also include full unprefixed support.Mozilla Firefox – The experimental header has been supported since version 4, however, version 23 includes full unprefixed support. Mobile versions support X-Content-Security-Policy only. Safari – CSP is supported through the X-Webkit-CSP header. Internet Explorer – IE 10 supports (very) limited subset of CSP is supported via the X-Content-Security-Policy header. In addition to governing JavaScript, CSP has a suite of directives to control where many variations of content is loaded from. This includes images, fonts, audio, video, frames and more.
Reporting CSP 1.1 introduces reporting capabilities. When a violation of your policy occurs, the user’s web browser will send the violation details in JSON format to a destination of your choosing. It should be understood that this does open the door to new abuse cases and should be used with the same caution as any other functional component of your application. CSP can also operate in “report only” mode, where policies are not enforced, but reports of violations will still be sent to you. This can be very useful to test out a policy before deployment. CSP can be difficult to determine just how it will affect a large application. To use CSP in this mode, the policy should be delivered via the following header:
Content-Security-Policy-Report-Only: […]
Policy Generation Policies will often be best generated by hand, but using a generation tool will give you something to start with. Mal Curtis has a very useful CSP generation tool that can get you started quickly making a policy. Further reading: Up to date details for browser support – http://caniuse.com/contentsecuritypolicy HTML5 Rocks Tutorial – http://www.html5rocks.com/en/tutorials/security/content-security-policy/ Full CSP 1.1 specification working draft – https://dvcs.w3.org/hg/content-security-policy/raw-file/tip/csp-specification.dev.html