- From: Tyler Close <tyler.close@gmail.com>
- Date: Mon, 30 Nov 2009 11:00:56 -0800
- To: Martin J. Dürst <duerst@it.aoyama.ac.jp>
- Cc: Adam Barth <w3c@adambarth.com>, Julian Reschke <julian.reschke@gmx.de>, HTTP Working Group <ietf-http-wg@w3.org>
On Wed, Nov 25, 2009 at 5:17 PM, "Martin J. Dürst" <duerst@it.aoyama.ac.jp> wrote: > On 2009/11/26 6:34, Tyler Close wrote: > >> My impression is that the undefined consensus understanding of the >> Same Origin Policy incorporates the rule that no API (not just a >> specific API, such as HTML form) can allow a cross-origin PUT, unless >> the target resource has somehow opted out of SOP protection. This >> rule, and others like it, are the source of much of the complexity in >> CORS. These rules are not left to the application layer. > > If I write something like a webbot, I can execute whatever PUT requests (or > other HTTP requests) I want, or can't I? Depending on how your webbot obtains the target URL, it may be violating the target resource's expectation for protection under SOP. For example, ... > An API such as libcurl > (http://curl.haxx.se/libcurl/) doesn't contain any such restrictions, or > does it? If you use libcurl to send a PUT request and the target resource responds with a 307, which libcurl then automatically follows, you may have violated the target resource's expectation of protection under SOP. 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. --Tyler -- "Waterken News: Capability security on the Web" http://waterken.sourceforge.net/recent.html
Received on Monday, 30 November 2009 19:01:36 UTC