W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2010

Re: HTTP access control confusion

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Fri, 30 Jul 2010 16:45:38 -0400
Message-ID: <4C5339F2.3020009@mit.edu>
To: Douglas Beck <dbeck@mail.ucf.edu>
CC: public-webapps@w3.org, Jared <jslang@mail.ucf.edu>
On 7/29/10 11:10 AM, Douglas Beck wrote:
> The basis of our confusion:
> I create domain-a.com and I want to make an ajax request to
> domain-b.com. A preflight request is made to domain-b, domain-b responds
> with if it is safe to send the request.
>
> Does it not make more sense for me (the author of domain-a) to define
> the security policy of my website?

I think the source of your confusion is that HTTP access control in the 
above scenario is protecting domain-b from domain-a.  It's not 
protecting domain-a.  Thus the security policy needs to be defined by 
domain-b.

> I know each and every request that
> should be made on my site and can define a list of all acceptable
> content sources.

The point here is that domain-a should not be able to get data from 
domain-b using the user's credentials that it wouldn't be able to get 
otherwise.  No one here is trying to protect domain-a from getting the 
"wrong" data or something.

> A more functional example (and the source of my curiosity), I work for
> the University of Central Florida. I am currently working on a subdomain
> that wants to pull from the main .edu TLD. The university has yet to
> define an Access-Control header policy, so my subdomain is unable to
> read what's available on the main .edu website.

Unfortunately, there's no obvious way to distinguish your situation from 
an attack on the main .edu website trying to get unauthorized 
information from it...

> Additionally, if I am working with authorized content, it would be
> useful for me to define/limit where cross-site requests can be made.

This is legitimate useful use-case.  The proposed technology for 
handling it is 
http://people.mozilla.com/~bsterne/content-security-policy/details.html 
(see the "xhr-src" directive).

> It seems backwards that an external source can define a security policy
> that effects the usability of my content.

Here's an illustration of what HTTP access control is supposed to prevent.

A user visits your website.  You do an XHR to a bankofamerica.com URL on 
the off chance that the user is a Bank of America customer and is 
currently logged in.  If this XHR were allowed you would at the very 
least be able to read information about the user's account, and 
depending on the setup of the bankofamerica.com site may be able to do 
things like transfer money.  _That_ is the threat HTTP access control is 
meant to mitigate.  While it might be convenient if you could show the 
user information about their bank account on your site in some 
circumstances, that's something the bank (or ideally the user, but 
that's harder to set up) needs to opt into.

Hope that helps,
Boris
Received on Friday, 30 July 2010 20:46:13 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:40 GMT