Content Security Policy (CSP) is a HTTP header that instruct the browser to limit resource loading of media, styles and scripts.
As you may know, CSP is not adopted yet by industry. Multiple surveys have already been made about the adoption of the security header   . Even so, it does not mean that we cannot prepare ourselves for the technology. For this purpose, we have built a Burp and ZAP extension to automate the most common validations called CSP Auditor.
The first component is the passive scanning that find various issues around the CSP configuration. The issues are visible from the Target tab when selecting the targeted host.
For manual review of the CSP header(s), an additional tab is available to display a readable version of the CSP configuration. It will display inherited properties. Those properties occur for example if
script-src is missing but
default-src is defined. The weak configurations are also colored according to the impact (orange for low severity and red for medium). This tab is available in most contexts such as History, Repeater and Intruder.
The passives rules
Now, what are the actual validations done by the extension? Here is the complete list. It can also be used as a checklist if a manual review is needed.
1. Unsafe inline
</script>) or event handlers (
2. Unsafe eval
By default, CSP does not allow the execution of
setTimeout functions. The
'unsafe-eval' directive disable this protection. An attacker might be able to take advantage of those risky scripts using eval to trigger a XSS. The directive’s presence is not a confirmation that
By specifying a wildcard, an attacker will be able to load a script from any server. Having this sort of directive eradicate the XSS protection capability from CSP.
Some libraries – namely AngularJS – have known payloads that allow the execution of script without using typical script html tag or event handler. In the case of Angular, CSP does not limit angular custom template syntax.
5. Allowing hosts that allow users’ content
Content delivery network (CDN) and software as a service (SAAS) are widely used. It is easy to introduce a permissive directive mistakenly. In the example above, the developer could have wanted to allow the hosts : myapplication1.appspot.com, myapplication1-api.appspot.com and myapplication1-files.appspot.com. Unfortunately, the wildcard cannot be used because anybody can register its own appspot subdomain (AppEngine).
6. Deprecated header name
X-Content-Security-Policy: ... / X-Webkit-CSP: ...
Some browsers have supported an experimental implementation of CSP with different header names. Now that the CSP specification 1.0 is out the older header should not be used.
This extension can be added to your web application assessment arsenal. However don’t expect to find a majority of sites implementing an efficient protection against XSS. Inline scripts are still widely used.
We cannot expect applications to be rewritten completely but, we can expect that the web frameworks will eventually adopt the standard. CSP Level 3 and its “nonce-source” are likely to make the adoption easier.
- Content Security Policy Reference : A handy reference to quickly getting started
- CSP 2015 by filedescriptor: Article describing the remaining attack vectors once CSP is configured properly.
- XSS without HTML: Client-Side Template Injection with AngularJS by Gareth Heyes: One of the most common CSP bypass
- CSP Auditor on GitHub : Get the source code of CSP Auditor
- CSP Bypass (Burp plugin) by Joe Moloch : Burp extension similar to CSP Auditor written in Python.
- Content Security Policy : Level 1
- Content Security Policy : Level 2
- Content Security Policy : Level 3