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