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:24:44 -0800
Message-ID: <5691356f0911301424x4b5a669clc7020b64392b9fa4@mail.gmail.com>
To: Daniel Stenberg <daniel@haxx.se>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Hi Daniel,

Thanks for engaging with this example. I think it's a useful one
because it makes it clear that this issue is independent of HTML...

On Mon, Nov 30, 2009 at 1:00 PM, Daniel Stenberg <daniel@haxx.se> wrote:
> On Mon, 30 Nov 2009, Tyler Close wrote:
>> Consider a webbot that sends a PUT request to a resource on the open
>> Internet, which responds with a 307 to a resource behind the same firewall
>> as the webbot. The webbot has essentially punched a hole in the firewall.
>
> If a server does that I would consider that server/page to be a security
> problem or flaw. Even evil guys can run webbots I believe.

In this scenario, the webbot and the person executing it are good
guys. The initial PUT request target resource is an evil guy, beyond
the control of good guys. 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?

Note that it may be legitimate for a good guy PUT request target
resource to respond with a 307 redirect to a resource that is not
protected by a firewall. So you can't just say: don't follow any
redirects. Some redirects are safe and some may not be, depending on
the provided Location header.

--Tyler

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

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