- From: Jonas Sicking <jonas@sicking.cc>
- Date: Tue, 9 Jun 2009 15:40:50 -0700
- 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