It is often seen that developers are not confined to the limits of their own domains. When you make requests through JavaScript across domains, the browser prevents the request from going through citing the absence of an \u2018Access-Control-Allow-Origin\u2019 header. This is termed as the \u2018Same Origin Policy\u2019 of browsers which allows scripts running on a domain to make requests to resources on the same domain only, comprising the same URI scheme, domain and host number. There are many ways around the same origin policy- ranging from routing the request through a web proxy to using CORS (Cross Origin Resource Sharing), but the most popular method is using JSONP.<\/p>\n
JSONP simply refers to \u201cJSON with padding\u201d. It is essentially a JSON response wrapped around a callback function that is specified in the URL. For instance, the following a JSON response.<\/p>\n
{\u00a0\u201cusername\u201d: \u201csdaityari\u201d,\u00a0\u201cname\u201d: \u201cShaumik Daityari\u201d}<\/p>\n
The same response with a callback function specified as processData is as follows.<\/p>\n
\u00a0processData({ \u201cusername\u201d: \u201csdaityari\u201d, \u201cname\u201d: \u201cShaumik Daityari\u201d})<\/p>\n
As browsers don\u2019t allow requests to other domains, how then do we add external files to CDNs (Content Delivery Networks) to speed up page loading and still get them to work? The hidden agenda is here is the fact that these files are present under the src attribute of <script> tags. This leads to a conclusion that anything under the <script> tags is executed by the browser under the context of the current domain!<\/p>\n
Using the same idea, we supply a callback function, generally as a GET variable, to the src in the <script> tag, and we get a response of a JSON wrapped with the callback function. That essentially means that the callback function is executed with the JSON response as arguments. That helps in working around applications just like we did in the case of AJAX.<\/p>\n
In the JSONP example provided, we would execute the function like the following-<\/p>\n
\u00a0<script src=\u201dhttp:\/\/www.example.com\/json_data?callback=processData\u201d><\/script><\/p>\n
By doing so, processData would be executed with the given arguments.<\/p>\n
In place of a JSON response padded within a function, if the server just returned a JSON, the data would not get executed, instead raising a Syntax Error. You could emulate a response by pasting some JSON into your JavaScript console.<\/p>\n
In the example above, the data that was returned through JSON was not so sensitive. It just contained the username and name. However, imagine an ecommerce site which stores credit card details as a part of your profile. Let\u2019s assume the following request being made-<\/p>\n
<script src=\u201dhttp:\/\/api.myecommercesite.com\/profile?callback=processData<\/a>\u201d><\/script><\/p>\n The website api.myecommercesite.com<\/a> would return the following response irrecpective of the website that requested the information.<\/p>\n \u00a0processData({<\/p>\n \u00a0\u00a0\u00a0\u201cname\u201d: \u201cShaumik Daityari\u201d,<\/p>\n \u00a0\u00a0\u00a0\u201ccard_no\u201d: \u201cxxxx xxxx xxxx xxxx\u201d,<\/p>\n \u00a0\u00a0\u00a0\u201cexpiry_date\u201d: \u201cxx-xxxx\u201d<\/p>\n \u00a0});<\/p>\n In the ideal case, this data is received by the intended website and used accordingly. However, let\u2019s say that a malicious site, www.attacker.com<\/a>, gets wind of the information and tricks you into redirecting you to their server.<\/p>\n Basically, you are browsing www.attacker.com<\/a> and you are asked to click on something. Their server then sends the same response and since you are logged into the ecommerce site, data containing your information is returned. (There are other non-JSONP related security checks which can prevent this from happening, but let\u2019s assume there were no other security measures to prevent this from happening.)<\/p>\n Once a malicious site gets hold of the sensitive data, it can process the data on the context of the site, and therefore do whatsoever it wishes with the data, most probably storing it in their own servers for later use. Not only this, a malicious site can also get hold of your cookies which contain vital information that a website uses to track your progress on its site.<\/p>\n The reason JSONP got so popular is the ease of use and implementation. All you need is a callback and you are done. Therefore, there are many security concerns which need to be taken care of while using this technique.<\/p>\n This is one little thing that can lead to dangerous consequences. In fact, many tutorials talking about the security in the JSONP method fail to get this one right. In PHP, you would generally execute the following.<\/p>\n \u00a0echo $_GET[\u201ccallback\u201d] . \u201c(\u201c . json_encode($my_data) . \u201c);\u201d;<\/p>\n In addition to that, vulnerabilities in JSONP have also been identified through a term called flash injection.<\/p>\n The right way, as explained by Dylan Tack<\/a> on his blog, is to use appropriate headers to manipulate the output in case the callback is being used for an XSS attack. He uses the following code-<\/p>\n function generate_jsonp($data) {<\/p>\n \u00a0if (preg_match(\u2018\/\\W\/\u2019, $_GET[\u2018callback\u2019])) {<\/p>\n \u00a0\u00a0\u00a0\/\/ if $_GET[\u2018callback\u2019] contains a non-word character,<\/p>\n \u00a0\u00a0\u00a0\/\/ this could be an XSS attack.<\/p>\n \u00a0\u00a0\u00a0header(\u2018HTTP\/1.1 400 Bad Request\u2019);<\/p>\n \u00a0\u00a0\u00a0exit();<\/p>\n \u00a0}<\/p>\n \u00a0header(\u2018Content-type: application\/javascript; charset=utf-8\u2019);<\/p>\n \u00a0print sprintf(\u2018%s(%s);\u2019, $_GET[\u2018callback\u2019], json_encode($data));<\/p>\n }<\/p>\n Using the JSONP requires that you trust the remote domain fully. This essentially means that if, for some reason, the functionality remote domain breaks, your service breaks too. It remains your decision, however, whether you want to depend on a third party service.<\/p>\n Moreover, as we are using it under script tags, it is difficult to catch errors within it and error handling changes from browser to browser, making it difficult to manage a proper structure.<\/p>\n For argument\u2019s sake, a possible way to login a user into a remote site using only JSONP would involve sending the username and password as GET variables (since that is the only way HTTP requests can get you the data in a script tag). It is an unsafe method of authentication and therefore, should be avoided.<\/p>\n For the purpose of user authentication, it\u2019s favourable that you follow the general workflow of OAuth- redirect to parent website, authenticate the user and on successful authentication, generate and share a token.<\/p>\n In case you are using the JSONP technique to write data to your server (whether it\u2019s create or update), you must know that JSONP uses GET, which is not secure. In order to make sure that everything goes according to plan, you could issue a token within the headers of every request. A token needs to be generated for every user who is authenticated using the step above.<\/p>\n That being said, there are far better options considering security during writes, updates or deletes and you should follow them rather than finding workarounds with JSONP, which should ideally be used for reads only.<\/p>\n We have seen a few use cases of JSONP and all of them can be achieved by the web proxy method too. Although the JSONP technique remains popular, the vulnerabilities in it make it a headache to implement in complex situations. CORS has been gaining popularity steadily as its support in major browsers continues to grow, and it\u2019s taking over the uses of JSONP.<\/p>\n \u00a0\u00a0\u00a0request = new XDomainRequest();<\/p>\n \u00a0\u00a0\u00a0request.open(method, url);<\/p>\n \u00a0\u00a0\u00a0request.onload = function() {<\/p>\n \u00a0\u00a0\u00a0\u00a0\u00a0callback(req.responseText);<\/p>\n \u00a0\u00a0\u00a0};<\/p>\n \u00a0\u00a0\u00a0request.send(data);<\/p>\n The CORS process adds new HTTP headers to the request, which allows the server to serve resources, but only to requests from known and trusted domains. This means that if www.attacker.com<\/a> tries to access information from api.myecommercesite.com<\/a>, it would not be possible because api.myecommercesite.com<\/a> would not recognize www.attacker.com<\/a>! For further information on CORS, you could head over the Mozilla Developer Network<\/a>.<\/p>\n The only drawback of CORS is the lack of support from older browsers and if you don\u2019t care about users with those old browsers, you should definitely go ahead and give CORS a try.<\/p>\n","protected":false},"excerpt":{"rendered":" Using JSONP for cross domain requests It is often seen that developers are not confined to the limits of their own domains. When you make requests through JavaScript across domains, the browser prevents the request from going through citing the absence of an \u2018Access-Control-Allow-Origin\u2019 header. This is termed as the \u2018Same Origin Policy\u2019 of browsers […]<\/p>\n","protected":false},"author":1,"featured_media":0,"parent":0,"menu_order":0,"comment_status":"open","ping_status":"open","template":"","meta":[],"yoast_head":"\nHow does an attacker use it to get your data?<\/h3>\n
Using JSONP safely<\/h2>\n
Sanitize callback<\/h3>\n
Full trust on a different domain<\/h3>\n
User Authentication<\/h3>\n
Using CSRF tokens for write operations<\/h3>\n
Looking forward- using CORS (Cross Origin Resource Sharing)<\/h2>\n
How does CORS work?<\/h3>\n