[OpenAjaxSecurity] W3C Access Control vs JSONRequest

Kris Zyp kzyp at sitepen.com
Wed Jan 9 07:24:59 PST 2008


> * My preference among the two would be JSONRequest for various reasons:
> - JSONRequest puts decisions about who gets access to the data on the server rather than the client

Actually the opt-in security mechanism is more similiar to Access-Control than that (at least with GET). In both technologies, the server can be aware of cross-site requests by looking at headers (Referer-Root in AC, Domain in JR). However, the primary opt-in mechanism (that is how to take an existing server and add support for cross site requests) is still by adding a header that allows the client to allow access. With AC, one adds an Access-Control header that the browser uses to give access, and with JR one returns a response with a Content-Type of application/jsonrequest to indicate that the browser give access. In both cases, if you access an existing server that has not opted-in, the browser will be the one to deny access on the basis headers, not the server.
Both approaches provide sufficient information in requests that servers can implement their own access control based on domains (deny sending responses based on request headers, Domain or Referer-Root). 
When it comes to non-GET requests, they differ more. JSONRequest relies on the idea that most servers are not currently supporting requests with a JSON object as the request body (the only way to send a POST in JSONRequest) as the mechanism to ensure safety for current servers, where AC requires the Access-Control header negotiation process to allow access. It is worth noting that there are existing servers that accept POST requests with a JSON object, and these servers could start seeing cross-domain POSTs without any opt-in (although without cookies). In that respect, I think AC is perhaps a bit more robust approach.
One of the advantages of JSONRequest is very fast and secure parsing of JSON (no need to do an eval). I think one thing that could make XHR more of superset of the capabilities of JSONRequest, is if they added a responseJSON property/getter that would provide internal JSON parsing. I, personally, would lobby for that, if XHR/AC was the only choice. My article on the comparison is probably still of some value, even if I did get the header/cookie part wrong as you pointed out :)
http://www.json.com/2007/11/16/w3c-enabling-read-access-for-web-resources/
All that said, I think I have slight preference for AC, but I would have to think about it more.
Kris



- JSONRequest has a couple of security features that look attractive to me, such as timeouts and random timing support if there are errors
- I would argue that JSONRequest has what's needed (GET & POST, requirement that servers have to opt-in) and no more. To me, Access Control is unnecessary complicated due to its approach to do policy management on the client. In particular, I don't like the Allow/Deny features in W3C Access Control. I don't see it being useful except in wildcard scenarios, such as "*" (i.e., allow everyone) or to grant access to all subdomains within a single site
- JSONRequest doesn't send cookies, so less worry about CSRF

* I also expressed the opinion that it would be better if JSONRequest supported both JSON and XML payloads. (Some people are attempting to write up JSONRequest as an option because it only supports JSON. They also try to write-off JSONRequest because it doesn't solve their proclaimed need to achieve cross-domain access to XBL and XSLT files, which I think isn't the driving requirement.)

What does everyone else think? If there is a consensus of opinion from OpenAjax people, I can forward that to the W3C.



------------------------------------------------------------------------------


  _______________________________________________
  security mailing list
  security at openajax.org
  http://openajax.org/mailman/listinfo/security
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openajax.org/pipermail/security/attachments/20080109/bab410a3/attachment.html 


More information about the security mailing list