Every Bug Bounty hunter should know the evil smile of the JSONP over the browser’s Same Origin.

JSONP stands for JSON with Padding. It is a JavaScript technique to request the data from the server and can access without worrying about

In my previous write-up, I explain the JSON CSRF vulnerability and Now I came up with a technique to abuse the browser Same Origin Policy (SOP).

Introduction — JSONP & SOP:

JSONP stands for JSON with Padding. It is a JavaScript technique to request the data from the server and can access without worrying about cross-domain issues. Below are the features of the JSONP.

• JSONP does not use the XMLHttpRequest object.
• JSONP uses the <script> tag instead.
• JSONP doesn’t care about the browser SOP.

Don’t be confused, I will explain with a practical scenario to understand the above.

Same Origin Policy (SOP):

SOP is a default basic and critical web security feature, without this, the data you are sending over the internet is not safe.

Actually, the same origin policy is a little bit more complex and there are lot of different cases you have to consider.

A simple example to understand SOP

Basically, SOP prevents scripts from one origin to access private data on another origin.

In this below example, we can not access the “mail.google.com” domain data from another origin (example.com) using the Ajax request due to the browser Same Origin Policy.

Actually, there are some technical possibilities to bypass this policy, one of those techniques is JSONP.

Let’s discuss how I abuse the SOP security using the JSONP in one of the bug bounty program.

Observation:

Whenever I test the web application, I carefully observe the authentication mechanism of the application. If that is cookie-based authentication then I directly look for the CSRF and CORS mis-configurations.

Finally, I found a sensitive GET endpoint that reveals the account details in the response in the JSON format.

At first, I thought that I can grab the response by using the Ajax request. Because the server not throwing any error to the manipulated Origin header.

Let’s try with below CORS exploit script

For the above script, I faced the below error in the browser.

Of course, the browser doesn’t allow to access the data from another origin. Because the response doesn’t have the below headers.

Access-Control-Allow-Origin: *Access-Control-Allow-Methods: POST, GET, OPTIONSAccess-Control-Allow-Credential: true

So It is clear we can’t access the cross-origin data without these headers.

Now, the JSONP comes into the picture

To exploit this using the JSONP, we have to verify whether the endpoint is support for the JSONP or not.

To understand the JSONP behaviour programmatically please read this

To test this we have to append the “callback” parameter with a random value to the URL. Observe the below image carefully the response data is in the callback function **“testjsonp()”.** It means the endpoint have JSONP feature.

So we can exploit this using the below JSONP script.

Finally, we have accessed the data from the other origin without cross-origin error.

Remediation:

Don’t use the JSONP callback function on the sensitive endpoints. Because JSONP by default designed to bypass the same-origin policy.

Developers sometimes depend on this JSONP technique to overcome the cross-domain issue in the development stage. So they may forget to remove the code on the production build.

Conclusion:

This problem is occurred because of the lack of random token and the endpoint supports the JSONP callback function. So make sure the testers don’t miss any test case while testing. Understand the basics of CORS and learn different techniques that abuse browser default security behaviour.

Thanks for reading. If you like this write-up please follow me and stay tune for more hacking techniques.

Checkout my previous write-up that explain another technique to bypass the SOP using the URL parsers.