W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2009

Re: HTTPbis and the Same Origin Policy

From: Tyler Close <tyler.close@gmail.com>
Date: Mon, 30 Nov 2009 14:54:25 -0800
Message-ID: <5691356f0911301454r271ee7d9y3e213358963facce@mail.gmail.com>
To: Daniel Stenberg <daniel@haxx.se>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
On Mon, Nov 30, 2009 at 2:34 PM, Daniel Stenberg <daniel@haxx.se> wrote:
> On Mon, 30 Nov 2009, Tyler Close wrote:
>
>> The 307 redirect target resource is a good guy. The webbot and the
>> redirect target live behind the same firewall. The evil resource lives
>> outside the firewall. For the protection of the good guy resource, the
>> webbot must enforce the SOP, so that the redirect is not followed. No HTML
>> is involved in this scenario. Whose specification of the SOP is the webbot
>> enforcing? Of what assistance should libcurl be in enforcing the SOP?
>
> Oh right. I think understand what you're saying now. You want the HTTP
> client to somehow detect that it isn't allowed to follow redirects to that
> target (in that manner) and stop because a SOP somehow says so.

Yes.

> How do you suggest that would be told to the client?

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.

> Couldn't the TARGET here rather use Referer (or Origin or what not) to
> detect that there's a redirect coming from externally and ignore it?

It could, but it doesn't. Today, the target resource expects the SOP
to protect it from non-same-origin PUT requests.

> It clearly can't be HTTPbis material though, since in my eyes it seems to be
> a rather major extension or change of what HTTP is and what it allows today.

The thing is, it's not an extension or a change. It's the status-quo.
Existing resources depend upon clients enforcing the SOP. We've just
left it unspecified what those protections are. Currently, these
protections are a widely relied upon oral tradition.

--Tyler

-- 
"Waterken News: Capability security on the Web"
http://waterken.sourceforge.net/recent.html
Received on Monday, 30 November 2009 22:54:59 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:13 GMT