Bypassing CSP with JSONP Endpoints

By |Published On: March 30th, 2022|Tags: |

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:

Copy to Clipboard

And the response with the payload returned verbatim:

Copy to Clipboard

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:

Copy to Clipboard

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:

Copy to Clipboard

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:

Copy to Clipboard

Now let’s modify our previous request to use this to bypass CSP:

Copy to Clipboard

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/

Share with your network!
Get monthly updates from Hurricane Labs
* indicates required

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.