Bypassing CSP by Abusing JSONP Endpoints- 3 mins
This blog post discusses a technique that can be used to bypass CSP (Content Security Policy).
What is CSP?
“Content Security Policy (CSP) is an added layer of security that helps to detect and mitigate certain types of attacks, including Cross Site Scripting (XSS) and data injection attacks. These attacks are used for everything from data theft to site defacement or distribution of malware.” — Mozilla Developer Documentations
What is JSONP?
JSON with Padding (JSONP) is a technique used to request and retrieve data from a server without worrying about cross-domain, bypassing the Same-Origin Policy (SOP).
The concept works as the following:
JSONP APIs normally works by having a parameter that sets a callback, so that users of the JSONP API can freely use the API according to their code.
What if we enter:
as our callback?
If no proper sanitization is done on the JSONP endpoint, it will be reflected as the following:
So importing the JSONP callback via a script tag as the following:
will result in the following:
Let’s say that we have the following CSP policy on a website:
Content-Security-Policy: default-src 'self'
This policy basically blocks anything that does not load from within the same origin.
So for example, if twitter.com have an XSS, and there is a white-listed domain on the CSP rule called “example.com”, and this domain holds a JSONP endpoint, then the CSP policy for twitter.com will be bypassed by abusing the JSONP endpoint for example.com.
What to Do?
Developers That are Responsible for JSONP endpoints
Restricts the callback name to certain keywords, or disallow non alphanumeric from returning within the response. Furthermore, you should think about protecting against the Rosetta Flash exploit.
Whenever you face a Content Security Policy on an application, review all white-listed domains, and search for JSONP endpoints.
Review your white-listed domains for domains that hold JSONP endpoints. This can be a bypass for your CSP policy.