W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2010

Re: UMP / CORS: Implementor Interest

From: Tyler Close <tyler.close@gmail.com>
Date: Wed, 12 May 2010 18:41:37 -0700
Message-ID: <AANLkTinUG0kTxcSBZ4uNJKLDkySEq_vbc8YAhxmnLFeZ@mail.gmail.com>
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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:38 GMT