- From: Tyler Close <tyler.close@gmail.com>
- Date: Wed, 12 May 2010 18:41:37 -0700
- To: Dirk Pranke <dpranke@google.com>
- Cc: Adam Barth <w3c@adambarth.com>, Jonas Sicking <jonas@sicking.cc>, Devdatta <dev.akhawe@gmail.com>, Ian Hickson <ian@hixie.ch>, Arthur Barstow <Art.Barstow@nokia.com>, Anne van Kesteren <annevk@opera.com>, public-webapps <public-webapps@w3.org>
On Wed, May 12, 2010 at 5:36 PM, Dirk Pranke <dpranke@google.com> wrote: > On Wed, May 12, 2010 at 5:15 PM, Tyler Close <tyler.close@gmail.com> wrote: >> On Wed, May 12, 2010 at 5:07 PM, Adam Barth <w3c@adambarth.com> wrote: >>> On Wed, May 12, 2010 at 4:56 PM, Tyler Close <tyler.close@gmail.com> wrote: >>>> Both Adam and Dirk understood correctly. Ideally, I'd like an actual >>>> CORS example to work on, since I'd have to make analogies with >>>> postMessage(), and I've already made a ton of analogies, apparently to >>>> little effect. If people don't fully appreciate the relationship >>>> between <form> based CSRF and CORS based Confused Deputy, then we need >>>> an actual CORS application. >>>> >>>> Out of curiosity, who are the 3 parties involved in the facebook chat >>>> example? The little chat widget in the corner of the facebook page >>>> looks like a same origin application. >>> >>> Facebook uses a lot of different domains for different purposes. I >>> don't have a complete count, but at least a dozen. The chat feature >>> itself uses a bunch, possibly to get around various connection limits >>> in browsers. >> >> This doesn't seem like a good example then, since the attacker would >> have to be facebook itself. For robustness, I personally consider >> these scenarios when designing an application, but people on this list >> might not find it compelling. They might also argue that no attempt >> was made to protect against such a vulnerability. >> >>> Keep in mind that the browser's notion of an origin is often much >>> smaller than a single application, which is part of the reason web >>> developers are so keen on CORS. Many of them plan to use it only to >>> talk to trusted hosts without having to use goofy things like JSONP. >> >> Enabling this scenario is a fine thing, but it's not the scenario we >> should be using to test the security properties of CORS. UMP also >> enables communication between fully trusted participants. > > It seems like a fine scenario to me. We know people want to use CORS > for this purpose because it makes their code easier and cleaner (both > of which are nice security things in and of themselves). If both CORS > and UMP are secure for this use case, then an interesting question is, > which is easier to use? This is particularly relevant insofar as if > the existing JSONP-based solution uses cookies, since CORS would > support this but UMP wouldn't (meaning the degree of rework in the app > necessary to support the code would be higher). > > Note that I am not saying that this should be the only scenario to be > reviewed, but you shouldn't just pick and choose the cases that best > fit your hypothesis. Over the course of this discussion, I've taken every use-case, with every arbitrary constraint that anyone wants to add and shown a corresponding UMP solution, so it is grossly unfair to accuse me of picking and choosing cases. For this particular discussion, we were explicitly looking for an example of a Confused Deputy vulnerability in an actual CORS application. Such a thing doesn't exist in a scenario with only 2 parties and no attacker. When testing security properties, you need an attacker. All that said, if you want to compare the usability of CORS and UMP in a 2 party interaction between fully trusted participants, we can do that. Go ahead and sketch out the challenge problem and corresponding CORS solution. --Tyler -- "Waterken News: Capability security on the Web" http://waterken.sourceforge.net/recent.html
Received on Thursday, 13 May 2010 01:42:11 UTC