On Wed, May 12, 2010 at 5:36 PM, Dirk Pranke <[email protected]> wrote: > On Wed, May 12, 2010 at 5:15 PM, Tyler Close <[email protected]> wrote: >> On Wed, May 12, 2010 at 5:07 PM, Adam Barth <[email protected]> wrote: >>> On Wed, May 12, 2010 at 4:56 PM, Tyler Close <[email protected]> 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
