Re: UMP / CORS: Implementor Interest

On Wed, May 12, 2010 at 6:41 PM, Tyler Close <tyler.close@gmail.com> wrote:
> On Wed, May 12, 2010 at 5:36 PM, Dirk Pranke <dpranke@chromium.org> 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.

I apologize, I thought your intent was to do a security review of CORS,
which in my mind would show what situations it can be used safely and
what situations it can't, not just show the latter. The two-party situation
is interesting because it is a situation that cannot be solved today without
CORS or UMP. So, the point is that CORS can safely enable a class of
scenarios that are not possible otherwise. This is a non-trivial point given
the current discussion.

Besides, I thought part of the point of the argument is that sites that are
often considered to be trusted aren't, because of the possibility of SQL
injection, XSS, etc.

>
> 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.
>

I will send something shortly.

-- Dirk

Received on Thursday, 13 May 2010 17:54:48 UTC