- From: Tyler Close <tyler.close@gmail.com>
- Date: Tue, 9 Jun 2009 14:20:50 -0700
- To: Adam Barth <w3c@adambarth.com>
- Cc: public-webapps <public-webapps@w3.org>
On Tue, Jun 9, 2009 at 2:05 PM, Adam Barth<w3c@adambarth.com> wrote: > On Tue, Jun 9, 2009 at 1:47 PM, Tyler Close<tyler.close@gmail.com> wrote: >> So if a page from Victim origin sends a request to Attacker origin >> which is redirected to a URL at Victim origin, the server at Victim >> origin receives a request with user credentials for Victim origin and >> an Origin header value for Victim origin. > > That's correct. Notice that the victim site will need to generate a > POST request to the attacker. The attacker is not able to change the > POST data. Also, this sequence generates a warning dialog on Firefox. > The attack does not work in Safari because redirects always generate > GET requests. > >> The Origin I-D says: "don't >> do that" at the end of section 6; meaning there's no way to send a >> request to another origin unless you have complete trust for it. > > You can send a GET request. > >> That seems rather restrictive. Is there really no way to send a request to >> another origin without being vulnerable? > > Yes. It's the price we pay for using the same header name as CORS. > If we decide to mint a new header (which is similar, but not quite > identical to Origin-for-CORS), then we can improve on this point. > >> Wasn't that the whole point >> of creating a mechanism to replace JSON-P? > > The Origin header is not a mechanism to replace JSON-P. The > Origin-header-as-CSRF-defense is meant to mitigate CSRF > vulnerabilities. I had thought CORS, by it's use of Origin, was meant to be a safe replacement for JSON-P. I think both the Origin I-D and the CORS spec should state in their front sections that they are only to be relied upon for messaging between mutually trusting sites. That's a very different security model than I had initially assumed. --Tyler -- "Waterken News: Capability security on the Web" http://waterken.sourceforge.net/recent.html
Received on Tuesday, 9 June 2009 21:21:21 UTC