Re: ISSUE-18: Is JSONRequest an acceptable alternative to the current model? [Access Control]

public-appformats-request@w3.org wrote on 01/06/2008 12:30:32 AM:

>
> Jon Ferraiolo wrote:
> >  > You failed to reply to the XSLT and XBL remarks that the JSON
thingie
> >  > does not address. These are important use cases.
> >
> > IMO the JSON use case is a couple of orders of magnitude more important

> > than the XSLT or XBL requirements. JSON is a primary format for
> > cross-site data exchange today, and is likely to grow in usage in the
> > coming years as more people discover its virtues.
>
> It's very hard to do a fair comparison between JSON and cross-site XHR
> given that only JSON actually works today. So of course it's going to be
> the primary format today.

There are various people in the Ajax community, such as Doug Crockford, who
promote JSON instead of XML for data delivery. In fact, Doug designed
JSONRequest to only work with JSON. My opinion is that I would like to see
both XML and JSON as first class options, but if I had a choice between the
two, I would pick JSON because it is the technology used today for
cross-site data delivery by the leading edge developers and because a
JSON-based approach offers incremental approaches to the community whereby
web sites can deliver JSON to support today's dynamic SCRIPT tag hack in
today's browsers while also supporting newer browsers later that support
JSONRequest. Therefore, JSON/JSONRequest allows immediate adoption because
there is a straightforward fallback for old browsers (i.e., dynamic SCRIPT
tag).

Therefore, I would expect one of the Access Control requirements to say
"MUST support JSON as a primary data delivery format for web-based
services" versus what the spec does today, which is treat JSON as a
second-class format to XML. (I say "second-class" because it is possible
with the current Access Control spec to send access control PIs within the
XML content but with JSON the web site developers can only provide access
information via HTTP headers.)
>
> > Overall, I would prefer it if browsers would adopt JSONRequest rather
> > than Access Control. JSONRequest was designed carefully from a security

> > perspective, such as the random delay feature. It achieves its results
> > *without* sending cookies (the cookie feature in Access Control scares
> > lots of us because of CSRF issues). I recognize that the WAF committee
> > has spent lots of time and effort on the existing Access Control, but I

> > think the community would be better served by having browsers implement

> > JSONRequest instead. (JSONRequest would be even better if it allowed
XML
> > data in addition to JSON data.)
>
> I'm not sure why you think there's an either-or scenario here. Firefox 3
> will most likely support both JSONRequest (or some variant thereof, I'm
> not directly working on that part) as well as cross-site XHR using
> access-control.

Please let's not develop two new features that address the same objective.
The community needs to unify around one and only mechanism, be it Access
Control or JSONRequest or minor enhancements to the SCRIPT tag or something
else. The key objective is community-wide interoperability which is best
served by a single standard, not multiple standards. Besides confusing and
dividing the community with multiple features trying to address the same
thing, you double the extra hacker attack service.

If you go along with the single standard argument, then the question which
one standard (Access Control vs JSONRequest vs other) should be used? It
might be time for the WAF WG to take time to query the browser vendors and
the rest of the community for feedback on Access Control in general, but in
particular how it relates to JSONRequest. It is clear that Opera and
Mozilla are engaged in the Access Control spec, but what about the Safari
team and (probably more importantly) the IE team, particularly with regard
to security? What do the big web service providers think (Yahoo, Amazon,
Google, Salesforce, etc.)? Doug Crockford is with Yahoo and he invented
JSONRequest, but that was last year and I don't know whether he represents
Yahoo's entire position.

Incidentally, I am still not yet convinced that the community benefits from
any of the above, and that "none" might be the best answer. This gets back
to my question from a couple of weeks ago about what are the target use
cases for Access Control. Is it attempting to allow POST operations to
sensitive web sites such as banks? (I hope not.) Is it attempting to allow
multiple-sub-domain intranets to talk to talk with each other in a
convenient manner (that is more reasonable)? Is it attempting to support
read-only (GET) access to non-sensitive web services, such as government
weather services (more reasonable)? Is it attempting to support read-write
(GET/POST) access to non-sensitive community sites (e.g., Facebook or
MySpace)? It is hard to provide solid feedback unless we have a clear
understanding of what are the target workflows for the specification.

>
> A lot of people has said that sending cookies and auth credentials
> 'scares' them, however no one has been able to show that it does in fact
> introduce new attack vectors.

If Access Control becomes a standard and gets widely adopted, there are
definitely going to be new CSRF attack vectors if cookies are sent. I
believe one of the reasons the community has been too worried about Access
Control and CSRF is that many of us doubt that it will get widely adopted,
so therefore the risk is minimal.

But if it *were* widely adopted, here is one attack vector. There will be
tons of Web2.0 community sites using XHR and Ajax, and if Access Control is
popular, then a significant percentage of these web site will opt-in to
Access Control. It is human nature to take the easy route and develop web
sites that choose to Allow every web site (i.e., "*") for GET and/or POST
because many community-site web developers have little imagination about
the value of the information at their site. For example,
DalmationLovers.org might be advertising supported (with the advertisements
isolated in IFRAMEs) and might feel that the information in their database
is harmless. Now, let's suppose that one of the ads comes from evil.com and
includes a mouseover event handler that invokes XHR to the
DalmationLovers.org site, leveraging the session cookie for that site.
Users often post personal information (email, phone number, login,
password) within community web sites, and the web site might offer a POST
service that allows the email address to be changed and then another POST
service that will send your account information, including password, to be
sent to the designated email address. Using this information, the hacker
can try to login to various banks using the same login and password because
many people use the same logins and passwords for multiple sites.

>
> I'm also very curious to hear how JSONRequest intends to do
> authentication without sending cookies or auth credentials. Does it work
> with existing deployed servers? Can I write a CGI script on an existing
> apache server, or an ASP page on an existing IIS server that
> authenticates the JSONRequest?

I don't know what Doug Crockford had in mind here, but I probably wouldn't
use either Access Control or JSONRequest for a web site that had
authorization credentials, particularly for POST operations. I would
require that all such interaction with my web site came from complete web
pages that came from my site.

>
> > For XSLT and XBL, shouldn't browsers allow cross-site (GET) access in
> > the same way it does for CSS stylesheets and SCRIPT tags?
>
> Now *that* if anything would introduce new attack vectors, no? I
> personally hate the fact that CSS and SCRIPT can load data cross site
> and I would love to disable that ability in firefox and replace it with
> something more secure. Unfortunately that would break the web :(

Yes, those would be new attack vectors, but at least they have functional
similarities to existing features (XSLT ~= CSS, XBL ~= SCRIPT) and, most
importantly, these are GET operations only.

But I fully agree that there should be some way that *new* web sites could
tell browsers to go into a strict security mode that would disabled
cross-domain access, including disabling existing cross-domain support for
SCRIPT, IMG and other things. That way a mashup web site developer could be
sure that the only cross-site requests that were made were accomplished
only via approval from the mashup container logic rather than some nasty
hidden logic within one of the mashup components.

Jon

>
> / Jonas
>