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

Jon Ferraiolo wrote:
> 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.

I don't actually agree that a single standard is all we need. At least 
none of the standards I've heard proposed I think would cover all needed 
scenarios.

First of all JSONRequest is clearly not well suited for things like XSLT 
or XBL or any other scenario where you want to use an XML resource. Yes, 
JSON can be used to envelope XML data, but you couldn't put:

<?xml-stylesheet type="text/xsl"
    href="http://example.org/jsonrequest/xslt.js">

at the top of an XML document and have it work.

> 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.

I agree that making banks use this would make me nervous too. But then 
again, banks always make me nervous :)

The use cases I have in mind is to allow simple cross-site communication 
to allow mash-up style services. Including use of user specific data 
such as calendars.

Also to allow reusable resources like XBL2 widget sets, XSLT stylesheets 
etc. Ideally CSS, javascript and images would have used something like 
this to allow cross-site use of resources. If that had been done 
originally we wouldn't have the problem of hot-linked images.

>  > 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.

This does not seem like a new attack vector. If DalmationLovers.org has 
a service that lets you POST an email address to which all your personal 
data is sent, then they are hosed already. Anyone can write a web page 
with a <form action="dalmationlovers.org/personaldata.cgi"> that POSTs 
data to the DalmationLovers.org service. This POST will include the 
users cookies and auth credentials. That is how the web already works.

In fact, by not including cookies and auth credentials you are just 
giving yourself a false sense of security. Just like many sites use 
cookies or http auth to authenticate a user, other sites simply use the 
fact that you can reach the server as authentication. There are many 
servers sitting behind firewalls that don't use any means of 
authentication, but simply assume that as long as you can reach the 
server you are an employee or otherwise trusted party. So if JSONRequest 
relies on the lack of cookies and auth credentials to protect the user 
or server, how are these firewalled servers protected?

>  > > 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.

Yes, they are GET operations, but they let you read the result of the 
GET which is of huge importance. As a server operator I would be very 
upset if this was allowed.

Server vendors are already required to know that all of their content 
can be read cross server if the contents happen to look like javascript. 
I'd hate for the same to be true if their contents looked like XSLT 
(which only requires a single attribute to turn any arbitrary XML file 
into a stylesheet) or XBL.

> 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.

Something like that would be nice indeed. Though you could never be 
suare that only cross-site requests are made via approved mechanisms as 
older browsers are always going to be out there.

/ Jonas

Received on Tuesday, 8 January 2008 06:01:51 UTC