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 www.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 http://www.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 www.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/
The post Bypassing CSP with JSONP Endpoints appeared first on Hurricane Labs.
*** This is a Security Bloggers Network syndicated blog from Hurricane Labs authored by Steve Benson. Read the original post at: https://hurricanelabs.com/blog/bypassing-csp-with-jsonp-endpoints/?utm_source=rss&utm_medium=rss&utm_campaign=bypassing-csp-with-jsonp-endpoints
