W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2009

Re: Redirect and Origin

From: Jonas Sicking <jonas@sicking.cc>
Date: Tue, 9 Jun 2009 15:40:50 -0700
Message-ID: <63df84f0906091540v78a9a579x5c3229f4e24c8bd6@mail.gmail.com>
To: Tyler Close <tyler.close@gmail.com>
Cc: Adam Barth <w3c@adambarth.com>, public-webapps <public-webapps@w3.org>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:12:54 UTC