Comments on: Remote JSON - JSONP http://bob.pythonmac.org/archives/2005/12/05/remote-json-jsonp/ Bob's Rants Sat, 17 May 2008 15:23:18 +0000 http://wordpress.org/?v=2.5.1 By: bob http://bob.pythonmac.org/archives/2005/12/05/remote-json-jsonp/#comment-11069 bob Mon, 04 Jun 2007 21:43:22 +0000 http://bob.pythonmac.org/?p=188#comment-11069 No, it's completely different than the XSRF hole in gmail. Even if it was, the whole point of JSONP is cross-site requests anyway... so it's not really forgery nor a hole. No, it’s completely different than the XSRF hole in gmail.

Even if it was, the whole point of JSONP is cross-site requests anyway… so it’s not really forgery nor a hole.

]]> By: Kishore Senji http://bob.pythonmac.org/archives/2005/12/05/remote-json-jsonp/#comment-11066 Kishore Senji Mon, 04 Jun 2007 20:42:05 +0000 http://bob.pythonmac.org/?p=188#comment-11066 While the call back param option is really nice, we need to be really careful while operating of sensitive JSON data for mash-ups. This is exactly what caused the gmail contact list XSRF hole. Isn't it? http://jeremiahgrossman.blogspot.com/2007/01/gmail-xsrf-json-call-back-hackery.html While the call back param option is really nice, we need to be really careful while operating of sensitive JSON data for mash-ups. This is exactly what caused the gmail contact list XSRF hole. Isn’t it? http://jeremiahgrossman.blogspot.com/2007/01/gmail-xsrf-json-call-back-hackery.html

]]> By: Johan Sundström http://bob.pythonmac.org/archives/2005/12/05/remote-json-jsonp/#comment-4951 Johan Sundström Mon, 12 Feb 2007 13:54:33 +0000 http://bob.pythonmac.org/?p=188#comment-4951 Completely unmoderated javascript code injection (providing code containing any characters) is not a good idea, but what level of restraint would be? There is call some level of callback layout restrictions, and I would like to standardize a good practice, which is also ideally trivial to implement for JSONP providers. Forbidding parentheses goes a long way, but it still allows you to steal document.cookie by storing it in a variable. Forbidding = too slightly harms the most trivial JSONP consumption model (callback "my_variable="). Yahoo seems to have set the bar for themselves on limiting to US-ASCII alphanumerics, underscore, period and square brackets. There is some merit to that; for one thing it skips scenarios with unbalanced quotation marks in the callback name. The outcome is at least useful enough. I would find it useful if JSONP appeared as an informal standard (IETF RFC, informational, for instance), stating good practices, conformance criteria, and so on, simply to have a document to refer implementors and service providers to, without forcing a high level of understanding of the domain on them. I think I more or less volunteer to writing it, but I would like you to be on board, so to speak, as inventor, originator or similar, even if you do not pull the actual weight. It would mostly be something to cover up the hole until Crockford's JSONRequest is somewhere near as deployed as XMLHttpRequest is today, but that will take some time, and JSONP works now. It could just use a little help along the way, here and there. Completely unmoderated javascript code injection (providing code containing any characters) is not a good idea, but what level of restraint would be? There is call some level of callback layout restrictions, and I would like to standardize a good practice, which is also ideally trivial to implement for JSONP providers.

Forbidding parentheses goes a long way, but it still allows you to steal document.cookie by storing it in a variable. Forbidding = too slightly harms the most trivial JSONP consumption model (callback “my_variable=”). Yahoo seems to have set the bar for themselves on limiting to US-ASCII alphanumerics, underscore, period and square brackets. There is some merit to that; for one thing it skips scenarios with unbalanced quotation marks in the callback name. The outcome is at least useful enough.

I would find it useful if JSONP appeared as an informal standard (IETF RFC, informational, for instance), stating good practices, conformance criteria, and so on, simply to have a document to refer implementors and service providers to, without forcing a high level of understanding of the domain on them. I think I more or less volunteer to writing it, but I would like you to be on board, so to speak, as inventor, originator or similar, even if you do not pull the actual weight.

It would mostly be something to cover up the hole until Crockford’s JSONRequest is somewhere near as deployed as XMLHttpRequest is today, but that will take some time, and JSONP works now. It could just use a little help along the way, here and there.

]]> By: bob http://bob.pythonmac.org/archives/2005/12/05/remote-json-jsonp/#comment-3818 bob Wed, 07 Jun 2006 21:47:45 +0000 http://bob.pythonmac.org/?p=188#comment-3818 It's a new API, that del.icio.us does not support. It was a hypothetical example. The point of the parentheses is that it's not valid JavaScript without them, and you need valid JavaScript for a script tag. XMLHttpRequest is irrelevant, because you would use regular JSON for that. I think you're confused about the security implications. It's definitely not an attack vector for the server because all it does is concatenate strings. If there's already malicious code on the client, this is totally irrelevant. The only attack vector is stealing cookies from the JSONP-hosting server, which is why yahoo's version doesn't allow anything but a single identifier to be used as the callback. It’s a new API, that del.icio.us does not support. It was a hypothetical example.

The point of the parentheses is that it’s not valid JavaScript without them, and you need valid JavaScript for a script tag. XMLHttpRequest is irrelevant, because you would use regular JSON for that.

I think you’re confused about the security implications. It’s definitely not an attack vector for the server because all it does is concatenate strings. If there’s already malicious code on the client, this is totally irrelevant.

The only attack vector is stealing cookies from the JSONP-hosting server, which is why yahoo’s version doesn’t allow anything but a single identifier to be used as the callback.

]]> By: Evan http://bob.pythonmac.org/archives/2005/12/05/remote-json-jsonp/#comment-3817 Evan Wed, 07 Jun 2006 18:55:07 +0000 http://bob.pythonmac.org/?p=188#comment-3817 I am not completely clear about this. How does it stay compatible with existing APIs? You seem to use it with del.icio.us without any updates. And the point of the parentheses is so that the same API can be called via regular XMLHttpRequest, and the data saved via assignment, or from an offsite page via a script tag, and the data saved via the callback? I guess the parentheses is the thing I really don't get. Would it not be more safe to have the server call a pre-defined function name only? I am thinking about a situation where an attacker embeds some malicious call-back code in a GET url and includes it in an image tag or something like that. Maybe this is no different than including any old offsite .js file. Anyway... I am not completely clear about this. How does it stay compatible with existing APIs? You seem to use it with del.icio.us without any updates.

And the point of the parentheses is so that the same API can be called via regular XMLHttpRequest, and the data saved via assignment, or from an offsite page via a script tag, and the data saved via the callback? I guess the parentheses is the thing I really don’t get.

Would it not be more safe to have the server call a pre-defined function name only? I am thinking about a situation where an attacker embeds some malicious call-back code in a GET url and includes it in an image tag or something like that. Maybe this is no different than including any old offsite .js file.

Anyway…

]]> By: bob http://bob.pythonmac.org/archives/2005/12/05/remote-json-jsonp/#comment-3808 bob Fri, 26 May 2006 19:52:11 +0000 http://bob.pythonmac.org/?p=188#comment-3808 Yes, of course it is possible to build a proxy. Yes, of course it is possible to build a proxy.

]]> By: nicolas rolland http://bob.pythonmac.org/archives/2005/12/05/remote-json-jsonp/#comment-3806 nicolas rolland Fri, 26 May 2006 16:33:38 +0000 http://bob.pythonmac.org/?p=188#comment-3806 This is a much needed feature. I was looking at ways to integrate my del.icio.us (which has some JSON support) categories in my blogger blog, and I had the exact same idea. Now being a beginner in JS, I have what might be a stupid question : isn't it possible to build a bridge server that supports JSONP and forward the JSON calls? regards, nicolas rolland http://technofinance.blogspot.com This is a much needed feature.

I was looking at ways to integrate my del.icio.us (which has some JSON support) categories in my blogger blog, and I had the exact same idea.

Now being a beginner in JS, I have what might be a stupid question : isn’t it possible to build a bridge server that supports JSONP and forward the JSON calls?

regards,
nicolas rolland
http://technofinance.blogspot.com

]]> By: Benjamin Nowack http://bob.pythonmac.org/archives/2005/12/05/remote-json-jsonp/#comment-2815 Benjamin Nowack Mon, 20 Feb 2006 17:25:58 +0000 http://bob.pythonmac.org/?p=188#comment-2815 I like the idea very much, just added support for it to an RDF store (http://www.appmosphere.com/en-arc_rdf_store). cheers, bnj I like the idea very much, just added support for it to an RDF store (http://www.appmosphere.com/en-arc_rdf_store).

cheers,
bnj

]]> By: mike chambers http://bob.pythonmac.org/archives/2005/12/05/remote-json-jsonp/#comment-2775 mike chambers Thu, 12 Jan 2006 19:09:51 +0000 http://bob.pythonmac.org/?p=188#comment-2775 You describe ActionScript (the development language used for the Flash VM as: >a one-off moving target programming langage Just an fyi, but ActionScript is based on ECMA script. The current version is not 100% compatible (although very close). The next version aims to be 100% compatible with the next version of ECMA script. Just an fyi... mike chambers mesh@adobe.com You describe ActionScript (the development language used for the Flash VM as:

>a one-off moving target programming langage

Just an fyi, but ActionScript is based on ECMA script. The current version is not 100% compatible (although very close). The next version aims to be 100% compatible with the next version of ECMA script.

Just an fyi…

mike chambers

mesh@adobe.com

]]> By: bob http://bob.pythonmac.org/archives/2005/12/05/remote-json-jsonp/#comment-2741 bob Tue, 27 Dec 2005 02:28:39 +0000 http://bob.pythonmac.org/?p=188#comment-2741 The callback implementation that Yahoo! deployed is *almost* JSONP, but not quite. The difference is that callback filters out anything past the first identifier given in callback, so you don't have the opportunity to throw in an "del.icio.us style" assignment. Originally I had thought to do exactly what Yahoo! did, but I didn't see a reason not to just let arbitrary text get prepended because it allows for compatibillity with legacy API, and simplicity in some situations. The callback implementation that Yahoo! deployed is *almost* JSONP, but not quite. The difference is that callback filters out anything past the first identifier given in callback, so you don’t have the opportunity to throw in an “del.icio.us style” assignment. Originally I had thought to do exactly what Yahoo! did, but I didn’t see a reason not to just let arbitrary text get prepended because it allows for compatibillity with legacy API, and simplicity in some situations.

]]>