Comments on: JSONP…you're joking, right?

By: Tim

Tim — Wed, 19 May 2010 21:33:53 +0000

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/

By: Ryan Kennedy

Ryan Kennedy — Fri, 16 Oct 2009 23:29:57 +0000

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.

By: neimado

neimado — Wed, 14 Oct 2009 05:23:04 +0000

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.

By: jaa

jaa — Thu, 17 Sep 2009 06:36:33 +0000

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?

By: Tom Robinson

Tom Robinson — Tue, 08 Sep 2009 05:30:28 +0000

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.

By: Saikat Chakrabarti

Saikat Chakrabarti — Fri, 14 Aug 2009 20:22:33 +0000

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.

By: Dallas Gutauckis

Dallas Gutauckis — Wed, 12 Aug 2009 17:48:48 +0000

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(…)}

By: David-Sarah Hopwood

David-Sarah Hopwood — Mon, 06 Apr 2009 18:12:56 +0000

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.

By: Ryan Kennedy

Ryan Kennedy — Fri, 27 Mar 2009 18:11:40 +0000

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.

By: Gregers Gram Rygg

Gregers Gram Rygg — Thu, 26 Mar 2009 12:05:33 +0000

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