- From: Maciej Stachowiak <mjs@apple.com>
- Date: Wed, 02 Dec 2009 23:52:57 -0800
- To: Adam Barth <w3c@adambarth.com>
- Cc: Tyler Close <tyler.close@gmail.com>, "Martin J. Dürst" <duerst@it.aoyama.ac.jp>, Julian Reschke <julian.reschke@gmx.de>, public-web-security@w3.org
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