Re: FAQ & Use Cases

On Wed, 16 Jan 2008, Jon Ferraiolo wrote:
> 
> I appreciate the attention that the WG has put into trying to promote a 
> secure approach to deliverying POST requests, but IMO it would be better 
> to pursue a different technical strategy, such as what we see in 
> JSONRequest or something derivative of that. With JSONRequest, POSTs are 
> allowed without requiring a prior GET (or HEAD or OPTIONS). JSONRequest 
> also can be made available via a JavaScript implementation that works in 
> today's browsers. Its approach is simpler for everyone involved, both 
> server-side developers and client-side (i.e., JavaScript) developers. 
> I'm not sure if JSONRequest is perfect as is (e.g., only supports JSON 
> and not XML), but it was designed by Doug Crockford, who gives talks at 
> Ajax conferences on web security, and IMO he has a good handle on 
> security issues.

The original proposed for Access-Control had no preflight check for POST, 
however, we added it because browser vendors said they would refuse to 
implement this spec without a preflight check. So our hands are rather 
tied here. In any case, being _more_ secure is hardly a problem, and we 
have the preflight cache to deal with the inefficencies. Given the very 
strong security feedback we got asking for the preflight checks, what are 
the reasons to _not_ have the preflight checks? Do they outweigh the 
securit concerns raised?


> As I have said previously, I disagree that XBL (and XSLT) should impact 
> decisions about how to provide the best technology for cross-site data 
> access. The XBL and XSLT specs can say that user agents must allow 
> cross-domain access, just as is allowed for CSS stylesheets.

As the XBL editor, I assure you that that will never happen. It would be a 
security disaster of epic proportions. XBL2 effectively allows the remote 
binding to be handled as a generic document; if access was granted to such 
a document without concern to cross-domain access then we would basically 
be exposing all XML documents on intranets to the outside world. There's 
no chance that that will be considered acceptable.


> Where did the idea of user-specific widgets come from, anyway? IMO, that 
> would be a very, very low priority (approaching zero).

I disagree.


> There are other approaches to sending data to a 3rd party domain that 
> are more secure and still achieve the same result. Once again, 
> JSONRequest does not send cookies. I assume that Doug Crockford assumes 
> that authenticated information (if necessary) would come from be sent 
> with the payload (rather than via cookies), which means that if domain 
> FOO wants to upload data to domain BAR, then domain FOO's web page would 
> require the user to someone enter their BAR authentication information 
> (which could be stored in FOO's cookies, not BAR's cookies). With such 
> an approach, the user will be told by FOO's web page that this web page 
> needs his BAR account information, so the user gets to opt-in to 
> allowing the cross-site POST, instead of the current approach in Access 
> Control where cookies (potentially with credentials) are always sent 
> without the user being aware.

The whole point is that we don't want the first party to be aware of the 
credentials. If they are sent with the request, then _there_ you are 
introducing a security hole.


> Access Control does not have a good mechanism for achieving 
> server-controlled session management with such a random token, largely 
> because it uses a client-side PEP approach. In fact, Access Control gets 
> in the way of the way most server developers would implement CSRF 
> protection.

The _whole point_ of a cross-site POST request is to enable CSRF. I don't 
understand under what conditions you would expect a server to _not_ accept 
a POST from a page from a remote server, if it is providing a service to 
all servers.


> I have yet to see important use cases where it makes sense for a 
> particular domain FOO to allow access to a particular domain BAR.

Google is likely to wish to constrain certain services to particular 
domains based on a contractual agreement with those domains.


> Since MS and Apple are not participating in the discussion so far

Actually both Microsoft and Apple were part of the discussions that led to 
the current design. It is you who is late to the table. :-)


> What the above paragraph translates into is that I would like to see a 
> requirement that says something about it being highly desirable that the 
> mechanism can run in today's browsers as they exist today (without 
> requiring the addition of a new browser plugin).

If it was already possible, we wouldn't need a new standard. I agree that 
it would be great if it was already possible. If JSONRequest provides what 
you need, and is already possible, then I suggest using it.


> IMO opinion, the XSLT and XBL specs should simply say that user agents 
> should allow cross-site access, just like what happens today with CSS 
> and JavaScript. Don't need Access Control for that.

Given that we have already seen attempts to break cross-site restrictions 
with CSS, I can assure you that XBL will not be making the same mistake. 
However, Access Control with its PI provides a very neat and simple 
solution.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Wednesday, 16 January 2008 21:00:51 UTC