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 [1] [2] [3]. 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 extension

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.

The weakness is highlighted in the Raw Response Tab.

 

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.

Detail view tab

 

The extension was submitted to the BApp Store and should be available in the next months. If you want to try it now, you can grab the plugin from the GitHub repository.

 

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-src: 'unsafe-inline'

In order to contain the JavaScript being executed, CSP allows only the execution of JavaScript within separate files.  With this directive enabled, an attacker will be able to use script html tag (<script></script>) or event handlers (onloadonerror, etc.) to load malicious JavaScript code.

2. Unsafe eval

script-src: 'unsafe-eval'

By default, CSP does not allow the execution of eval or 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 eval() or setTimeout() are used. Old JavaScript libraries are often the reason why ‘unsafe-eval’ is added.

3. Wildcards

script-src: *

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.

4. Risky hosts with known vulnerable JavaScript

script-src: *.googleapis.com

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

script-src: *.appspot.com

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.commyapplication1-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.

 

Conclusion

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.

 

References

GoSecure Titan® Managed Extended Detection & Response (MXDR)​

GoSecure Titan® Managed Extended Detection & Response (MXDR)​ Foundation

GoSecure Titan® Vulnerability Management as a Service (VMaaS)

GoSecure Titan® Managed Security Information & Event Monitoring (SIEM)

GoSecure Titan® Managed Perimeter Defense​ (MPD)

GoSecure Titan® Inbox Detection and Response (IDR)

GoSecure Titan® Platform

GoSecure Professional Security Services

Incident Response Services

Security Maturity Assessment

Privacy Services

PCI DSS Services

Penetration Testing Services​

Security Operations

MicrosoftLogo

GoSecure MXDR for Microsoft

Comprehensive visibility and response within your Microsoft security environment

USE CASES

Cyber Risks

Risk-Based Security Measures

Sensitive Data Security

Safeguard sensitive information

Private Equity Firms

Make informed decisions

Cybersecurity Compliance

Fulfill regulatory obligations

Cyber Insurance

A valuable risk management strategy

Ransomware

Combat ransomware with innovative security

Zero-Day Attacks

Halt zero-day exploits with advanced protection

Consolidate, Evolve & Thrive

Get ahead and win the race with the GoSecure Titan® Platform

24/7 MXDR FOUNDATION

GoSecure Titan® Endpoint Detection and Response (EDR)

GoSecure Titan® Next Generation Antivirus (NGAV)

GoSecure Titan® Network Detection and Response (NDR)

GoSecure Titan® Inbox Detection and Reponse (IDR)

GoSecure Titan® Intelligence

ABOUT GOSECURE

GoSecure is a recognized cybersecurity leader and innovator, pioneering the integration of endpoint, network, and email threat detection into a single Managed Extended Detection and Response (MXDR) service. For over 20 years, GoSecure has been helping customers better understand their security gaps and improve their organizational risk and security maturity through MXDR and Professional Services solutions delivered by one of the most trusted and skilled teams in the industry.

EVENT CALENDAR

LATEST PRESS RELEASE

GOSECURE BLOG

SECURITY ADVISORIES

 24/7 Emergency – (888)-287-5858