Re: Redirect and Origin

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