Re: HTTPbis and the Same Origin Policy

On Dec 3, 2009, at 10:02 AM, Tyler Close wrote:

> On Wed, Dec 2, 2009 at 11:52 PM, Maciej Stachowiak <mjs@apple.com>  
> wrote:
>>
>> 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.

I have mentioned before that I believe the set of cases where CORS  
requires preflight may be more restrictive than provably necessary.  
CORS also specifically *is* concerned with the case of resources that  
are protected solely by a firewall, because the conditions of my point  
(2) do not necessarily apply for requests that do not meet the "simple  
cross-origin request" criteria.

Do you see an actual flaw in my reasoning as applied to the command- 
line tool in question?


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

That may be so, but "curl -L -d ..." will not send a different Content- 
Type unless the user explicitly sets a Content-Type header with  
additional options.

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

I think it is correct that blindly following redirects even in a  
relatively low-level client may expose resources behind firewalls to  
unexpected requests, and that this may pose security risk. I'm not  
sure there is risk beyond that unless the client executes script that  
it receives, processes HTML, or otherwise behaves in a browser-like  
way. We should probably figure out the scope of the risk and a  
recommendation for mitigating it before debating whose job it is to  
document it.

Regards,
Maciej

Received on Thursday, 3 December 2009 18:38:27 UTC