Re: HTTPbis and the Same Origin Policy

On Wed, Dec 2, 2009 at 11:36 PM, Daniel Stenberg <daniel@haxx.se> wrote:
> On Wed, 2 Dec 2009, Tyler Close wrote:
>
> (ietf-http-wg removed from the CC list)
>
>> """
>> The SOP rule is something like: Don't follow a cross-domain redirect
>> of a PUT request, unless the redirect target has opted out of SOP
>> protection.
>>
>> So, upon seeing the 307 redirect, libcurl would report an error if the
>> origin of the Request-URI does not match the origin of the URL in the
>> Location header; otherwise, the redirect is followed. Until there's a
>> standard way for a resource to opt out of SOP, that's the best that
>> can be done.
>> """
>
> Won't this get the user into the publicsuffix problem basically? I mean, if
> my company has two vhosts under a single domain, shouldn't they be
> perferctly possible to redirect back and forth between each other?
>
>   foo.example.com redirecting a POST to bar.example.com

For GET and POST requests that can be sent by the HTML form element,
following the redirect is allowed by SOP. For more detail on the
redirects allowed by SOP, see:

http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/att-0931/draft.html

So, foo.example.com may be allowed to redirect a POST to
bar.example.com, or any other origin.

The SOP networking restrictions on requests only come into play for
methods other than GET and POST, or for POST requests that have
certain headers. Thats why I've been using PUT in this discussion.

> That's quite different than foo.com redirecting to bar.com. But just as with
> cookies, we can't really tell the difference just by looking at the names -
> as the names don't reveal the topology.

SOP does allow some mucking around with the domain name topology (via
document.domain), but AFAIK, this wouldn't allow foo.example.com to
PUT to bar.example.com.

--Tyler

-- 
"Waterken News: Capability security on the Web"
http://waterken.sourceforge.net/recent.html

Received on Thursday, 3 December 2009 17:37:38 UTC