Re: Redirect and Origin

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.

Adam

Received on Tuesday, 9 June 2009 21:06:48 UTC