On Tue, Jun 9, 2009 at 1:47 PM, Tyler Close<[email protected]> 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. Adam
