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: Wed, 2 Dec 2009 11:52:15 -0800
Message-ID: <5691356f0912021152w6d5e88d9j365d4291a84bed38@mail.gmail.com>
To: Joe Gregorio <joe@bitworking.org>
Cc: "Manger, James H" <James.H.Manger@team.telstra.com>, HTTP Working Group <ietf-http-wg@w3.org>, public-web-security@w3.org
Meta note: This message is CC'd to both ietf-http-wg and the new
public-web-security list
<http://lists.w3.org/Archives/Public/public-web-security/>. I gather
that TPTB want this discussion moved to public-web-security, so please
treat this email as the splice in the conversation and remove
ietf-http-wg from the CC list of any replies.

On Tue, Dec 1, 2009 at 7:00 AM, Joe Gregorio <joe@bitworking.org> wrote:
> On Mon, Nov 30, 2009 at 5:52 PM, Manger, James H
> <James.H.Manger@team.telstra.com> 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.
>>
>> This actually is covered by the HTTP spec (1.1 and HTTPbis).
>> For instance, 8.3.8 307 Temporary Redirect says:
>>
>>   If the 307 status code is received in response to a request method
>>   that is known to be "safe", as defined in Section 7.1.1, then the
>>   request MAY be automatically redirected by the user agent without
>>   confirmation.  Otherwise, the user agent MUST NOT automatically
>>   redirect the request unless it can be confirmed by the user, since
>>   this might change the conditions under which the request was issued.
>>
>> [http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-08#section-8.3.8]
>>
>> At the HTTP layer it is not a same-origin issue, but a wider issue with methods that are not "safe".
>
> I've covered these scenarios in httplib2 with the .folllow_redirects
> and .follow_all_redirects options:
>
>   http://httplib2.googlecode.com/hg/doc/html/libhttplib2.html#httplib2.Http.follow_redirects
>
> Tyler, are you asking for HTTP client libraries to provide something
> more comprehensive than that?

Yes, to assist implementation of a webbot that obeys the SOP, it would
be useful to have a setting to follow only redirects that are allowed
by the SOP. For example, see the discussion in:

http://lists.w3.org/Archives/Public/ietf-http-wg/2009OctDec/0272.html

"""
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.
"""

This setting would follow more redirects than your
Http.follow_redirects, but fewer than Http.follow_all_redirects. The
latter setting follows redirects that violate SOP, and so is
dangerous.

--Tyler

-- 
"Waterken News: Capability security on the Web"
http://waterken.sourceforge.net/recent.html
Received on Wednesday, 2 December 2009 19:52:49 GMT

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