Re: [cors] TAG request concerning CORS & Next Step(s)

On Wed, Jun 24, 2009 at 1:37 PM, Jonas Sicking<jonas@sicking.cc> wrote:
> On Wed, Jun 24, 2009 at 12:52 PM, Tyler Close<tyler.close@gmail.com> wrote:
>> Hi Jonas,
>>
>> I'm just asking what Origin header behavior will be shipped in Firefox
>> 3.5. You've said redirects of preflighted requests aren't supported,
>> so I'm wondering about the non-preflighted requests.
>
> It will have the Origin header of the original request. We're
> considering blocking the request entirely for now though.

Meaning the POST request is delivered to Site A, with an Origin header
also identifying Site A, but with a Request-URI chosen by Site B. So
Site B can cause the POST request to be sent to any resource on Site A
and be processed under Site A's authority. I recommend against
shipping that algorithm.

Note that this scenario is just a special case of a more general
problem with the Origin proposal. Whenever a page issues a request
that includes data provided by a third site, that page is applying its
own authority to identifiers provided by the third site. This is the
essence of a CSRF attack (Confused Deputy). For example, if a page
from Site A does a GET to Site B and then includes a received
identifier in a subsequent POST to a site other than Site B, Site A is
vulnerable to a Confused Deputy attack by Site B. Since the whole
point of cross-origin requests is to enable this kind of passing of
information between sites, the Origin proposal is poorly suited for
access-control in these scenarios.

Again, see my paper "ACLs don't" <http://waterken.sf.net/aclsdont/>
for an in-depth explanation of why ACL model solutions, such as
Origin, can't solve this problem. The section on stack introspection
is especially relevant, as Origin is a degenerate form of stack
introspection.

>> Another question, since Firefox doesn't support redirects of
>> preflighted requests, what does it do when it encounters a redirect?
>
> It aborts and denies the original request. For XHR that means raising
> an error event.

It's worth wondering whether web pages will come to rely on these
requests being aborted and so be vulnerable should a future release
not abort the requests.

--Tyler

-- 
"Waterken News: Capability security on the Web"
http://waterken.sourceforge.net/recent.html

Received on Wednesday, 24 June 2009 21:27:15 UTC