- From: Tyler Close <tyler.close@gmail.com>
- Date: Tue, 3 Nov 2009 17:33:48 -0800
- To: Maciej Stachowiak <mjs@apple.com>
- Cc: "Mark S. Miller" <erights@google.com>, Anne van Kesteren <annevk@opera.com>, "Henry S. Thompson" <ht@inf.ed.ac.uk>, Jonas Sicking <jonas@sicking.cc>, Arthur Barstow <Art.Barstow@nokia.com>, public-webapps <public-webapps@w3.org>
I was just catching up on email and thought it might be useful to respond to this one even though it's a couple weeks old now, since in general the group seems to want more examples. On Mon, Oct 12, 2009 at 7:19 AM, Maciej Stachowiak <mjs@apple.com> wrote: > As a side note, I should add that Tyler's scenario would be much simpler > overall if printer.example.net used a grant of read access to the photo it > wants to print on storage.example.org, instead of granting write access to a > new location. In this scenario, photo.example.com has the opportunity to take the role of attacker in a CSRF-like attack. In the legitimate case, photo.example.com is expected to send a URL to printer.example.net which identifies the photo to be printed, such as <http://storage.example.org/photo123>. In the attack case, photo.example.com could send the URL that identifies the printer.example.net client list, such as <http://storage.example.org/clients123>. Consequently, photo.example.com receives a print out of the printer.example.net client list, instead of a photo printout. > Or it can just ask photo.example.com to read the photo from > storage.example.org and send the actual data. Either of these much less > abusable than writing, and would be a safer approach, whether or not the > overall design depends on secret tokens. The grant of read access can be > one-time or time-limited if necessary. Thus, I think the scenario is > somewhat contrived. Likely cross-site interactions would not involve such a > complex process to transfer data. The root of the vulnerability in Tyler's > scenario is writing in a shared namespace to transfer data, instead of > simply granting read access to the existing copy, or transferring the actual > data bits. The semantics of the request, read versus write, are not relevant to the attack. As Maciej explained in the TPAC meeting today, the actual problem occurs when a request is composed using data received from 2 or more sites. As an historical note, it's interesting to observe the initial misstep here and so conjecture that web developers may also misunderstand the dangers and so use CORS-with-Origin in an insecure way. A request composed from data received from 2 or more sites should be a common pattern in any *cross-origin* application. It's the nature of the problem space. There's no need for examples to be complicated to demonstrate the problem. If people find Maciej's example simpler, it demonstrates the vulnerability just as well. --Tyler -- "Waterken News: Capability security on the Web" http://waterken.sourceforge.net/recent.html
Received on Wednesday, 4 November 2009 01:34:21 UTC