Re: HTTPbis and the Same Origin Policy

On Wed, Dec 2, 2009 at 11:52 PM, Maciej Stachowiak <mjs@apple.com> wrote:
>
> On Dec 2, 2009, at 10:01 PM, Adam Barth wrote:
>
>> On Wed, Dec 2, 2009 at 11:36 AM, Tyler Close <tyler.close@gmail.com>
>> wrote:
>>>
>>> This same reasoning applies to the "stylebot" example in Adam Barth's
>>> message. The "stylebot" can be implemented without violating SOP
>>> restrictions.
>>
>> Can you explain this in more detail?  The stylebot reads a "program"
>> from one origin and gives that program read/write access to another
>> origin.  Sounds like a violation of the SOP to me.  Of course, for my
>> application, it's perfectly fine because these "programs" are written
>> by members of the WebKit community and both servers belong to the
>> WebKit community.
>
>
> The command-line tool "curl", when invoked with -L and -d options, violates
> Tyler's proposed SOP restrictions for bots. It seems like a more clear-cut
> example than the stylebot. Specifically, "curl -L -d ..." will follow a
> cross-site 307 redirect with a POST. <http://curl.haxx.se/docs/manpage.html>
>
> I believe the potential for this to create a vulnerability is quite limited:
>
> 1) For this to create a new vulnerability, the target of the redirect must
> use a firewall (or in general network position) as the sole access control
> factor. This is so because, for any host on the public Internet, an attacker
> can issue a request at any time, without having it redirected by an
> exploited client. And curl does not send any authentication tokens (neither
> HTTP auth nor cookies nor anything else) to the target of a redirect. So any
> request you could get curl to send this way, by reporting a 307 redirect,
> you could send yourself if the host were on the public internet. If the
> target of the redirect used cookies, HTTP auth, SSL certs a "secret token"
> defense or pretty much anything besides just a firewall, it would reject the
> request.

If you truly believe the above, then CORS should not require a
pre-flight request when the credentials flag is false. I suspect you
actually believe the above point is weak, since CORS does require a
pre-flight for these requests.

> 2) For this to create a new vulnerability, the target of the redirect must
> specifically be vulnerable to something in the request that can occur with
> "curl -L -d ..." but would not ever be sent normally by a browser as part of
> browsing or form submission. This is so because otherwise, the target of the
> redirect would already have a CSRF vulnerability. However, unless the user
> issuing the curl command goes out of his or her way to add unusual custom
> headers or override the Content-Type or request body, this will not occur.
> The redirect itself cannot change the body or alter headers.

There's no need to change the Content-Type. The initial malicious
target simply says its API is: "POST me some application/xml". Nothing
strange about that. It then redirects the request to a resource behind
the firewall.

> After analyzing this particular situation, I am not sure it makes sense to
> apply the same-origin policy as-is to low-level HTTP clients as opposed to
> browser-like clients. There may be some variant of the same-origin policy
> that some subset of low-level network clients should consider.

It's that last sentence there that is my whole point. Deployed HTTP
resources depend upon the part of the SOP that restricts what requests
can be made cross-origin, and what parts of the response are made
accessible to the requestor. HTTPbis should document that part of SOP.
IMO, they are shirking their charter if they don't.

Quoting from the charter:
"""
The working group will refine RFC2616 to:
...
* Document the security properties of HTTP and its associated
echanisms (e.g., Basic and Digest authentication, cookies, TLS) for
common applications
"""

--Tyler

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

Received on Thursday, 3 December 2009 18:03:29 UTC