[OpenAjaxSecurity] W3C Access Control vs JSONRequest

Jon Ferraiolo jferrai at us.ibm.com
Wed Jan 9 09:17:30 PST 2008

Hi Kris,
Yes, your table is still useful. Any chance you can correct the statement
about cookies?

One *big* advantage I see to JSONRequest is that the industry could start
using its APIs immediately via an Ajax library that delivers JSONRequest.
This new Ajax library would check to see if the browser supports
JSONRequest natively, otherwise the features are accomplished by using
existing features (i.e., dynamic script tag) under the hood. You should
know more about this than anyone since you have implemented JSONRequest in
JavaScript within CrossSafe: http://code.google.com/p/crosssafe/. :-) To
me, making magic work in today's browsers (versus waiting years for a new
spec to be implemented) is one of the tenets of Ajax.

Also, I see various negatives with Access Control as currently formulated.
Here are three things in particular. I agree with Doug Crockford on the
cookie issue (i.e., I think cookies should not be sent automatically by the
browser). Second, I think policy management belongs on the server, not the
client (i.e., Allow/Deny shouldn't be on the client). Third, I dislike how
the Allow/Deny feature works in Access Control where a discrete list of
domains are whitelisted and blacklisted because I don't see use cases where
the lists provide value worth the complexity.


             "Kris Zyp"                                                    
             <kzyp at sitepen.com                                             
             >                                                          To 
             Sent by:                  "OpenAjax Alliance Security Task    
             security-bounces@         Force" <security at openajax.org>      
             openajax.org                                               cc 
             01/09/2008 07:24          Re: [OpenAjaxSecurity] W3C Access   
             AM                        Control vs JSONRequest              
             Please respond to                                             
             OpenAjax Alliance                                             
               Security Task                                               
             <security at openaja                                             

> * 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 :)
All that said, I think I have slight preference for AC, but I would have to
think about it more.

- 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
 security mailing list
 security at openajax.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openajax.org/pipermail/security/attachments/20080109/d145d707/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
Url : http://openajax.org/pipermail/security/attachments/20080109/d145d707/attachment-0003.gif 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pic32436.gif
Type: image/gif
Size: 1255 bytes
Desc: not available
Url : http://openajax.org/pipermail/security/attachments/20080109/d145d707/attachment-0004.gif 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ecblank.gif
Type: image/gif
Size: 45 bytes
Desc: not available
Url : http://openajax.org/pipermail/security/attachments/20080109/d145d707/attachment-0005.gif 

More information about the security mailing list