Re: Redirect and Origin

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.

/ Jonas

Received on Tuesday, 9 June 2009 22:41:47 UTC