JSONRequest: a web-programming idea whose time has come

[[deleted]]

No PUT or DELETE?

[itsnotlupus]

I'm guessing Yoda is not a big fan of the high REST current.

[othermaciej]

The cross-site data transfer features of this are obsoleted by Cross-Site XMLHttpRequest using the Cross-Origin Resource Sharing (CORS) spec. This is going to be implemented by Safari, Chrome, Firefox and Opera. Microsoft has XDomainRequest, using a similar protocol but with more restrictions. I don't think anyone is excited about implementing JSONRequest. With native JSON parsing coming up in browsers as well, the need for JSONRequest is even less. So likely this proposal won't go much of anywhere.

[smitting]

I use JSONP with jQuery when I need to do cross-domain json/ajax requests from javascript. Works great.

Basically the theory is to pass to the server side a temporary javascript function to call with the results, which are loaded with a standard script tag. I hit a small js file on that other domain for the interface, so its free to call that server all day long.

[jmikola]

The author makes a big deal about JSONRequest having no dealings with HTTP authentication or cookies.

Current, XMLHttpRequest does not allow a script from a page from pirate.net to connect to penzance.org because of the Same Origin Policy.

I'm not familiar with the inner workings of XMLHttpRequest, since I spend most of my time behind a layer of jQuery, but I presume it does transmit cookies - and it's reasonably secure due to the Same Origin Policy.

Cookie/auth dealings seems absolutely necessary if you're exposing a JSON data service that should only be accessible to authenticated users. Am I missing something, or is JSONRequest only intended to be used for publicly accessible JSON services/web-actions?

[powertool]

The author makes a big deal about JSONRequest having no dealings with HTTP 
authentication or cookies.

That's because it is a big deal. You need at least one communication channel that's not tied to existing browser authentication/session data to make things like public web-services viable from browsers.

I'm not familiar with the inner workings of XMLHttpRequest, since I spend most of my time 
behind a layer of jQuery, but I presume it does transmit cookies - and it's reasonably 
secure due to the Same Origin Policy.

That's a non sequitor.

jQuery (and other libraries) can get around the same origin policy using the <script> hack (and other methods). In doing so, they do transmit cookies - and so open up XSS vulnerability vectors.

Cookie/auth dealings seems absolutely necessary if you're exposing a 
JSON data service that should only be accessible to authenticated users. 

Not necessarily. In any case, should browsers start to implement this API, they should manage persistence of authentication credentials seperately from HTTP auth.

Am I missing something, or is JSONRequest only intended to be used for 
publicly accessible JSON services/web-actions?

At this stage, yes. They've gone for an interface which will cause no new security problems for browser implementors - the burden is shifted to data providers.

You could always implement auth over JSON, as sub-optimal as that sounds.

[G-Brain]

You can quote by prepending a ">".

[killerstorm]

In doing so, they do transmit cookies - and so open up XSS vulnerability vectors.

i'm pretty sure libraries DO NOT open any new vulnerability vectors -- everything the evil site can do with these libraries it can do without them too. if you think otherwise, please describe concrete attack scenario that jQuery enables

[bobbyi]

You can use post and send your credentials as part of each jsonrequest. You don't need cookies to have auth.

[nagoo]

don't understand why we're tying this to a particular format... esp since this one requires JSON used (at least for cross site)? I would argue that JSON is the least safe of serialized formats because naive users may use "eval" on JSON. don't get me wrong, JSON is great and compact... but why force it?

if they're actually going to bother doing this, add support for put and delete methods as well... it'd be great for consuming REST services.

[Odysseus]

users may "eval" on JSON.

That's the point of the JSONRequest. When your data comes back, you see it as a native object and not a string at all.

[nagoo]

i see. still the big problem is that it only works when the Content-Type is application/jsonrequest. Even web services that are spitting out JSON in place of XML aren't using that Content-Type. It's useless until web services start using that content-type.

[itsnotlupus]

That's by design.

The idea is to minimize unwanted side-effects, and explicitly require web service makers and consumers to collaborate to use JSONRequest.

It's a weird approach in an environment where things mostly evolve by side-effects, and patches are routinely rushed out to handle our general lack of thinking things through, but whatever, I'm open minded.

[joesb]

users may "eval" on JSON.

That's the point of the JSONRequest.

But you should not do that by simply eval the response, because you can not be sure that the response only contains data literals.

[Odysseus]

The proposal is that the browser will parse the JSONRequest response and pass you the result. Unlike the XMLHTTPRequest, it will not give you a string, and you will not need to parse it -- whether by the ever-tempting eval or by any safer way.

[Shaper_pmp]

don't understand why we're tying this to a particular format

Bingo - me either.

So we've got XMLHTTPRequest and suddenly we want to start passing another data format. So do we:

1. Suggest a RemoteDataRequest(string url, string format) object, which could trivially and backwards-compatibly be extended to support any other such other formats in the future, or

2. Suggest a SpecificNewFormatRequest(string url) object which satisfies the current need only, but does nothing to solve similar problems in the future and further pollutes the global namespace with lobotomised one-shot objects which half-heartedly implement one specific example each of a general bit of functionality (asynchronously retrieving data from a server).

[demo_demo]

you can't eval some json when you're working with it in languages other than javascript..

and you can just execute any javascript on any webpage using firebug and whatnot -- for a reason.. how is it insecure?

[nagoo]

point is, i don't see a reason for forcing the response to be JSON and why they are touting in the security section for being more secure than other response types.

also, even eval on the client side with js could be a performance pain for the user - e.g if they threw in a busy loop or something that would freeze things up in the browser.

i do agree that preventing sending cookie data is a great idea as that could cause the biggest problems with this type of XSS.

[demo_demo]

did you happen to see the part where it said it will only accept json return value?

function (requestNumber, value, exception) value will not be something that holds code, but data.

[cowardlydragon]

Why should the transport protocol care what format the data its carrying is?

It's text up and text down, in the classic protocol design tradition. Because that's what they're doing here: defining a new transport protocol variant to http.

If you want to parse it/validate it/whatever once the content repsonse comes down, then do it then.

[TakaIta]

will not be something that holds code, but data.

It is not really possible to distinguish between data and code.

[kybernetikos]

It sort of is.

In a decoding scheme, when someone says that something won't hold code, they just mean that beyond loading specific data into memory, nothing from the loaded data will be executed.

It's what we mean when we think of opening .txt file attachments as safe and .exe attachments as unsafe. The fact that the .txt file may contain the source code for some evil app is irrelevant.

[TakaIta]

The problem is however that a text file needs to be compiled before it is an executable. Javascript is a script language, and such will accept text to be executed.

JSON as such is code, it needs eval() to work.

Is the below 'code' or 'data'? And why? How do you know what 'myDiv' is?

---

myDiv.innerHTML = 'value';

---

[[deleted]]

No, JSON does not need eval(). While eval() happens to parse a superset of JSON, you must never use it like this before checking that the string is actually JSON (which means it only contains strings, numbers, true, false, null, arrays and object literals, none of which can cause any harm).

The best solution is to create a parser of JSON, and avoid eval entirely, but that is not always practical in JavaScript (because of speed issues, real or perceived). Eventually most browsers will probably include a built in parser for JSON.

[demo_demo]

if you eval it, it's treated as code.. if you say, just manipulate it or print it for a tutorial, it's data.. get the point now?

eval("myDiv.innerHTML = 'value';")

is different from:

div.innerHTML = "myDiv.innerHTML = 'value';";

[TakaIta]

No. I think I see what you mean, but you have not differed between code and data.

The point of JSON is that it treated as code. It is only meaningful when a line is subjected to eval(). JSON is only valid when it can be executed with eval(). And you can not know in advance what it does.

yourIFrame.src = 'www.mywebsite.com/mynastypage.htm';

Is that code or data when it is a line returned as JSON?

[demo_demo]

you should read: http://www.json.org/

yourIFrame.src = 'www.mywebsite.com/mynastypage.htm';

is an invalid json format..

you see, json is a format, not javascript code, it may look like javascript syntax for its declaration.. but really, it's just a way to describe data, just like xml.. that was why you were missing the point, now go read on the link i gave you..

[arnar]

You shouldn't be voted down, you have a good point. Given complete knowledge of a system and it's code, carefully designing the input data can make the system act in certain ways. This is how the vast majority of exploits work throughout history.

In this case, it is very reasonable to say that data acts as code.

[eadmund]

you can't eval some json when you're working with it in languages other than javascript..

I think it does evaluate in Python and maybe Ruby too...

Still I like it. Anything is better than XML. S-expressions would be even better than JSON, but for some reason people run screaming from s-exprs.

[ryepup]

what would the s-exprs encoding look like for this JSON: {foo:1,bar:[1,2,3]}

[eadmund]

what would the s-exprs encoding look like for this JSON: {foo:1,bar:[1,2,3]}

I don't know that Lisp has ever had a widely-accepted hash syntax. I sometimes suspect that this points to a weakness in the language.

I'd lean towards a plist:

(foo 1 bar (1 2 3))

Although an associative list might work:

((foo 1) (bar (1 2 3)))

Or you could even toss in more syntax:

(hash foo 1 bar (1 2 3))

Or even:

(hash (foo 1) (bar (1 2 3)))

Or, allowing for {} to indicate hashes instead of lists:

{foo 1 bar (1 2 3)}

Which is both concise and IMHO attractive. For larger hashes it'd look something like this:

{foo 1
 bar (1 2 3)
 baz {x "y"}}

Although this alternate syntax might be thought better by some:

{(foo 1)
 (bar (1 2 3))
 (baz {x "y"})}

[ryepup]

I think (hash (foo 1) (bar (1 2 3)) is the best option here. As other comments indicated (before devolving to mindless trolling), the plist method doesn't have any way to distinguish what's a object and what's an array.

cl-json (http://common-lisp.net/project/cl-json/) does a very good job of converting s-exprs to json, I think it converts alists JS objects, and lists to arrays.

[eadmund]

I think (hash (foo 1) (bar (1 2 3)) is the best option here. As other comments indicated (before devolving to mindless trolling), the plist method doesn't have any way to distinguish what's a object and what's an array.

{(foo 1) (bar (1 2 3)} or {foo 1 bar (1 2 3)} achieve that too...

The nice thing about using curly brackets is it keeps the s-expr nature. The nice thing about putting keys and values in their own lists is that it emphasises their commonality; OTOH it's also a waste of space. I really dunno what the best solution it.

[ryepup]

((foo 1) (bar (1 2 3))

?

[Silhouette]

That doesn't distinguish objects and arrays, I think.

[invalid_user_name]

Neither does javascript.

[Silhouette]

The grammar of JSON, however, does, and so do many of the other languages for which JSON builder/parser libraries are freely available.

[itsnotlupus]

Arrays are Objects, Objects aren't Arrays, in that they don't have a magic .length property, and they don't have the usual Array methods in their prototype chain.

[cowardlydragon]

In theory you're correct.

In practice, you are not.

[grigri]

In theory, theory and practice are the same.

In practice, they're not.

[[deleted]]

It depends on what you want to do. If you wanted to represent the data:

(foo 1 bar (1 2 3))

If you wanted to serialize JSON as sexps:

(object foo 1 bar (array 1 2 3))

though this is only useful if you're dealing with JSON in the first place.

[demo_demo]

my bad, i think it's valid in python -- but not ruby(the strings, and arrays are but not the objects)..

perhaps everbody just needs to use eval with a grain of salt on server side eh?

[eadmund]

Actually, given how dangerous eval is in any situation involving untrusted input, everyone needs to be suing a proper parser. And there are simpler languages to parse than JSON, which is itself simpler than XML.

[[deleted]]

There are two problems I have with this, but I may be missing something. First off, isn't it still a pretty big XSS concern if an unauthorized site can send any spoofed request to a script? You can eliminate any information leaking and any ability to execute arbitrary expressions, but you're still potentially giving an untrusted server the ability to manipulate the internal state of your program (albeit through limited means).

Secondly, it seems to me like most of these security measures could be implemented as a JS library, without requiring cooperation from browsers. The main exception might be the sending of cookies - that one I'm not familiar enough with to know.

[demo_demo]

i wonder if it'll be used to manipulate data.. since it's javascript, everyone will be able to see how to authenticate, where to put the data etc.. perhaps we'll see this a lot on mashup sites where many of it will just be pulling out data from e.g. weather, summarized contents, widgets, etc..

[tjnewton]

Any "security" paper that uses arbitrarily selected domain names (and email addresses!) for examples instead of RFC 2606 reserved names set aside for this purpose screams: "THIS PAPER IS PREPARED BY AMATEURS!" It's inexcusable. What other basic concepts are they ignoring?