Re: Redirect and Origin

On Tue, Jun 9, 2009 at 3:40 PM, Jonas Sicking<jonas@sicking.cc> wrote:
> On Tue, Jun 9, 2009 at 3:05 PM, Tyler Close<tyler.close@gmail.com> wrote:
>> On Tue, Jun 9, 2009 at 2:52 PM, Adam Barth<w3c@adambarth.com> wrote:
>>> On Tue, Jun 9, 2009 at 2:20 PM, Tyler Close<tyler.close@gmail.com> wrote:
>>>> I had thought CORS, by it's use of Origin, was meant to be a safe
>>>> replacement for JSON-P.
>>>
>>> Can you explain again how the attack works for Origin-header-for-CORS?
>>>  Keep in mind that the response is delivered to the original
>>> requester, who should be accurately identified by the Origin header
>>> (even through redirects).
>>
>> But the side-effects of the request still happen. The attacker can
>> cause mutation of server-side state belonging to the victim user.
>>
>> I believe the scenario in the first email works as described in CORS.
>> I don't see anything in the CORS redirect steps that changes the
>> Origin processing from what is described in your I-D.
>>
>> http://www.w3.org/TR/access-control/#redirect-steps
>>
>> These documents really need to state that they are only addressing
>> messaging between mutually trusting sites.
>
> Hmm.. there does indeed seem to be a problem here.
>
> If site A issues a DELETE request to site B, using XHR and CORS, and
> site B redirects that request back to site A, then A will in effect
> perform a DELETE request on itself. At least assuming that A is
> configured to trust itself, which I think many sites will do.
>
> I'm in general not a big fan of the redirect model in CORS, but this
> one especially seems like a problem. One solution would be to include
> the full redirect chain (or change the Origin to 'null') if
> redirecting across servers with a non-safe HTTP method.

Your suggestion to include the full redirect chain would bring the
proposal closer to the general security model that Origin is part of
(though without crediting it), that of "stack introspection". The
Origin proposal is essentially a degenerate form of stack
introspection, where only the last two levels in the stack are
inspected. The HTTP cookies identify the top stack frame and the
Origin header identifies the immediately preceding stack frame. Note
that it is already known that full stack introspection doesn't
actually work to defend against CSRF, so I don't recommend going in
that direction. See my paper at:

http://waterken.sourceforge.net/aclsdont/

All of the vulnerabilities discussed in that paper also apply in the
web browser context. In addition, the situation is worse, since not
all stack frames are visible to the browser, since it only sees
interactions at the granularity of origins. For example, in a Caja,
ADsafe or Facebook scenario where widgets are running in the same
page, stack introspection of origins is useless, since there's only
the one origin. This whole approach is a dead end for where the Web is
today and is going tomorrow.

--Tyler

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

Received on Tuesday, 9 June 2009 23:01:39 UTC