Bypassing CSP with JSONP Endpoints
HTTP’s Content-Security-Policy (CSP) mechanism provides a means to instruct web browsers to apply various restrictions to the content returned by any given HTTP request. Such content could actually be under the control of a malicious party if a vulnerability such as Cross-Site Scripting (XSS) exists, which allows attackers to insert arbitrary script code into HTML due to improper handling of input.
A CSP policy can instruct browsers to only execute script code from particular sources, not the vulnerable returned content, and thereby providing a secondary layer of protection against XSS attacks.
There are some circumstances under which CSP policies can be evaded, however. This article will examine how to defeat a CSP policy abusing a JSONP endpoint that resides on a site that the CSP policy considers trusted.
A Demonstration of Breaking CSP with JSONP Endpoints
Example Website
First, let’s take a look at a page on our example website at example.com/csp, which contains a trivial XSS vulnerability.
A request with a XSS payload:
And the response with the payload returned verbatim:
Needless to say, this payload executes in a browser.
Now let’s try mitigating this using CSP. As part of our remediation efforts, we add a Content-Security-Policy response header as a safeguard against any XSS vulnerabilities on our site. We whitelist m.addthis.com because we use AddThis on some other pages on our example.com site.
Here’s the same response to the above request with our CSP:
We can now see that, thanks to CSP, the payload no longer executes in a browser. Furthermore, a violation error message is logged in the console:
There’s a problem, however. m.addthis.com contains a JSONP endpoint at /live/red_lojson/100eng.json.
Here’s an example of normal usage:
This JSONP endpoint at m.addthis.com is particularly helpful because the input is not sanitized at all. Anything in the callback query string parameter is returned verbatim as a script. We can change the callback parameter to make m.addthis.com return completely arbitrary Javascript:
Now let’s modify our previous request to use this to bypass CSP:
Now our Javascript payload is returned from the whitelisted m.addthis.com domain instead of example.com:
The CSP has been successfully bypassed and our code is executing thanks to the unconsidered JSONP endpoint in a whitelisted domain.
Conclusion
CSP is a powerful mechanism which can prevent the exploitation of XSS vulnerabilities. However, always remember that it is a secondary layer of protection. Always strive to fix vulnerabilities at their source rather than relying exclusively on a safety net.
References
Ebrahem Hegazy’s list of public JSONP endpoints useful for CSP bypass: https://github.com/zigoo0/JSONBee/blob/master/jsonp.txt
Google’s CSP Evaluator Tool: https://csp-evaluator.withgoogle.com/
About Hurricane Labs
Hurricane Labs is a dynamic Managed Services Provider that unlocks the potential of Splunk and security for diverse enterprises across the United States. With a dedicated, Splunk-focused team and an emphasis on humanity and collaboration, we provide the skills, resources, and results to help make our customers’ lives easier.
For more information, visit www.hurricanelabs.com and follow us on Twitter @hurricanelabs.
