Subject: W3C web security mailing list (Re: HTTPbis and the Same Origin Policy)

From: Thomas Roessler <[email-masked]>
Date: Tue, 1 Dec 2009 15:56:37 +0100

On 1 Dec 2009, at 04:25, Mark Nottingham wrote:

> This is important, but as mentioned firmly out of the scope of the HTTPbis WG. 
> 
> There's currently a lot of discussion along these lines both at the IETF and the W3C, and I expect that a new mailing list will be announced shortly to serve as a home for topics like this.

That announcement just went out:
  http://lists.w3.org/Archives/Public/public-web-security/2009Dec/0000.html

You're more than welcome to continue this thread on that list.

Additionally, here is a wiki page that attempt to collect most of the reference links that came up in this thread:
  http://www.w3.org/Security/wiki/Same_Origin_Policy

---

From: Joe Gregorio <[email-masked]>
Date: Tue, 1 Dec 2009 10:00:22 -0500

On Mon, Nov 30, 2009 at 5:52 PM, Manger, James H
<[email-masked]> 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?

   Thanks,
   -joe

> James Manger

---

From: Adam Barth <[email-masked]>
Date: Tue, 1 Dec 2009 07:09:33 -0800

On Mon, Nov 30, 2009 at 7:25 PM, Mark Nottingham <[email-masked]> wrote:
> Tyler,

The new mailing list appears to have materialized at
<http://lists.w3.org/Archives/Public/public-web-security/>.  I think
that would be a great place to discuss documenting the same-origin
policy.

Adam

---

From: Adam Barth <[email-masked]>
Date: Tue, 1 Dec 2009 07:10:39 -0800

Oops.  I should have read my whole inbox before replying.  Sorry for the noise.

Adam

---

From: Tyler Close <[email-masked]>
Date: Wed, 2 Dec 2009 11:36:22 -0800

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 Mon, Nov 30, 2009 at 8:28 PM, "Martin J. Dürst"
<[email-masked]> wrote:
> On 2009/12/01 4:00, 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.
>
> Yes, the webbot has done this. One has to be very careful when running stuff
> such as webbots, make sure they are either inside or outside the firewall,
> but not both, unless you know exactly what you're doing. This not only
> applies to PUTs, but also to GETs.

Yes, where obeying SOP rules is part of how you "be very careful".

> On the other hand, if I write (e.g. using libcurl or whatever) a "webbot"
> that periodically checks the balance on one of my bank accounts and
> transfers money from another bank account of mine if the balance on the
> first bank account is low, then I don't see why anybody would want to forbid
> this.

I am *not* suggesting it should be forbidden. Just as a user-agent
permits a user to copy-paste data between origins, so should a webbot
be permitted to do the same. The SOP rules apply to what content from
a given origin may be allowed to do, not to what the user may do. For
example, using your scenario, content from the first bank account (the
one you're are checking the balance of), should not be able to
determine the balance of the "another bank account". Only the webbot
should be able to do this.

This same reasoning applies to the "stylebot" example in Adam Barth's
message. The "stylebot" can be implemented without violating SOP
restrictions.

--Tyler

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

---

From: Tyler Close <[email-masked]>
Date: Wed, 2 Dec 2009 11:52:15 -0800

> 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