Saturday, March 11th, 2006

JSONRequest: Proposal for Cross-Domain Browser Service

Category: JavaScript, Remoting

<p>Douglas Crockford, creator of JSON, has proposed that browsers include a new “JSONRequest” service to allow for safe cross-domain calls.

JSONRequest is a service which encodes a JavaScript value as a JSON
text, does an HTTP POST of that text, gets the response, and parses
the response into a JavaScript value. If the parse was successful, it returns
the value to the requesting script. In making the request, no HTTP authentication or cookies are sent.
Any cookies returned by the server are discarded. The JSONRequest service
can only be used to send and receive JSON-encoded values. JSONRequest
cannot be used to retrieve documents or other texts.

JSONRequest is a global function. It takes four parameters:

parameter type description
url string The URL to POST to. The URL does not need to be related to the page’s URL.
send object The JavaScript object or array to send as the POST data. It will
be serialized as JSON text. Cyclical structures will fail.
done function (requestNumber, value, exception) The function to be called when the request is completed. If the request was successful, the function will receive the request number and the returned value. If it is not successful, it will receive the request number and an exception object.
timeout number The number of milliseconds to wait for the response. This parameter is optional. The default is 10000 (10 seconds).

It would be nice to have a safe component for cross-browser calls, though maybe an extension to XMLHttpRequest, not tied to a particular format like JSON, is preferable. Nevertheless, the article makes the case for a more constrained approach and lists several reasons why JSONRequest is safe enough for cross-domain requests:

  1. JSONRequest does not send or receive cookies or passwords in HTTP headers. This avoids false authorization situations. Knowing the name of a site does not grant the ability to use its browser credentials.
  2. JSONRequest works only with JSON text. The JSONRequest cannot be used to access legacy data or documents or scripts. This avoids attacks on internal websites which assume that access is sufficient authorization. A request will fail if the response is not perfectly UTF-8 encoded. Suboptimal aliases and surrogates will fail. A request will fail if the response is not strictly in JSON format. A request will fail if the server does not respond to POST with a JSON payload.
  3. JSONRequest reveals very little error information. In some cases, the goal of a miscreant is to access the information that can be obtained from an error message. JSONRequest does not return this information to the requesting script. It may provide the information to the user through a log or other mechanism, but not in a form that the script can ordinarily access.
  4. JSONRequest accumulates random delays before acting on new requests when previous requests have failed. This is to frustrate timing analysis attacks and denial of service attacks.

See Douglas’s article for all the motivation and technical details of the JSONRequest proposal.

Related Content:

Posted by Michael Mahemoff at 5:00 pm
11 Comments

+++--
3.6 rating from 25 votes

11 Comments »

Comments feed TrackBack URI

I’m trying to boil this down: JSONRequest would allow pages on domain A to exchange with domain B without having to give B access to A’s cookies/HTTP auth headers. As I understand it this currently can’t be done with current methods like dynamically creating SCRIPT elements..? True? What I don’t completely get is what inherent security there is in strictly enforcing scriptly UTF-8 JSON data.

Comment by Stephen Clay — March 11, 2006

I’m trying to boil this down: Essentially JSONRequest would allow pages on domain A to exchange with domain B without having to give B access to A’s cookies/HTTP auth headers..? As I understand it this currently can’t be done with current methods like dynamically creating SCRIPT elements..? What I don’t completely get is what inherent security there is in strictly enforcing scriptly UTF-8 JSON data. Of course the timeout feature is nice too, emulating data push from the server.

Comment by Stephen Clay — March 11, 2006

UTF-8 seems more like a play to avoid legacy stuff, by mandating a more modern, consistent method of encoding. By doing so, problems, security or otherwise, that might crop up in older implementations or in support code for older implementations are mitigated. I suspect that many security problems come from ambiguous requirements or specifications. By not having anything ambiguous, that leaves on less possible hole.

Comment by Andy — March 11, 2006

I think the spec is a good start, but a lot things still have to be hashed out. For example, I could do without these arbitrary limits propsed:

“Limits
There is a length limit on JSON texts of 250,000 Unicode characters. This limit is enforced in both directions. A request that exceeds the limit fails. In the worst case, 250,000 Unicode characters can consume 999,988 bytes.
JSON structures can be nested. A body with a nesting depth of 20 or more will be rejected.”

Also, the random delay thing to prevent timing analysis attacks don’t belong in the spec at all. This would provide little if no security above SSL at the expense of complicating any potential implementation.

All and all, it’s a good first draft. More debate is required.

Comment by Hugh — March 12, 2006

The full duplex functionality mentioned in the JSONRequest spec would be a very welcome addition to XmlHttpRequest as well. The current RPC-styled HTTP interaction is very limiting to web applications and leads to a great waste of bandwidth and adds too much latency to each call.

Comment by Hugh — March 12, 2006

JSONRequest Proposal

Although the idea is (generally) a good one, I have some suggestions for improvement of Douglas Crockford’s recent proposal for an XMLHttpRequest equivalent for JSON.

The overloads for the JSONRequest function are confusing, and the parameter n…

Trackback by Out of Hanwell — March 13, 2006

[...] Speaking of Douglas Crockford, a few people mentioned his JSONRequest spec, which I blogged a couple of months back on Ajaxian. This is gaining momentum – Brendan is bullish and mentioned that it’s trivial to implement – though Laurel (IE) didn’t say too much. Hey, even if it’s only in Firefox, we’re going to see some cool apps come out of it. The basic idea is a safe cross-domain caller (no cookie transfer). [...]

Pingback by Software As She’s Developed - The Ajax Experience, May, 2006 (SF) Wrapup — May 17, 2006

Deja Vu looks pretty interesting. Kilmer and Denzel are some of my favorite actors.

Comment by mr skin — October 25, 2006

I felt good about this post. It confirmed for me some of the things I’ve been thinking about.

Comment by services — October 26, 2006

Sounds like a great to me.

Comment by William Siebler — October 29, 2006

…I’d love to see this get implemented

Comment by Mark Holton — July 18, 2007

Leave a comment

You must be logged in to post a comment.