Re: HTTPbis and the Same Origin Policy

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.

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.

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.

Regards,
Maciej

Received on Thursday, 3 December 2009 07:53:38 UTC