Re: UMP / CORS: Implementor Interest

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