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.
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.
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.
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.
reflected-xss allow reflected-xss filter reflected-xss block
Has the following equivalents:
X-XSS-Protection: 0 X-XSS-Protection: 1 X-XSS-Protection: 1; mode=block
- 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.
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:
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.
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