Re: UMP / CORS: Implementor Interest

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:
>>> On Wed, May 12, 2010 at 4:45 PM, Adam Barth <w3c@adambarth.com> wrote:
>>>> On Wed, May 12, 2010 at 4:38 PM, Dirk Pranke <dpranke@google.com> wrote:
>>>>> On Wed, May 12, 2010 at 4:06 PM, Adam Barth <w3c@adambarth.com> wrote:
>>>>>> On Wed, May 12, 2010 at 3:16 PM, Tyler Close <tyler.close@gmail.com> wrote:
>>>>>>> On Wed, May 12, 2010 at 1:38 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>>>>>>>> On Wed, May 12, 2010 at 1:31 PM, Tyler Close <tyler.close@gmail.com> wrote:
>>>>>>>>> On Wed, May 12, 2010 at 1:13 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>>>>>>>>>> On Wed, May 12, 2010 at 12:38 PM, Devdatta <dev.akhawe@gmail.com> wrote:
>>>>>>>>>>> While most of the discussion in this thread is just repeats of
>>>>>>>>>>> previous discussions, I think Tyler makes a good (and new) point in
>>>>>>>>>>> that the current CORS draft still has no mention of the possible
>>>>>>>>>>> security problems that Tyler talks about. The current draft's security
>>>>>>>>>>> section
>>>>>>>>>>>
>>>>>>>>>>> http://dev.w3.org/2006/waf/access-control/#security
>>>>>>>>>>>
>>>>>>>>>>> is ridiculous considering the amount of discussion that has taken
>>>>>>>>>>> place on this issue on this mailing list.
>>>>>>>>>>>
>>>>>>>>>>> Before going to rec, I believe Anne needs to substantially improve
>>>>>>>>>>> this section - based on stuff from maybe Maciej's presentation - which
>>>>>>>>>>> I found really informative. He could also cite UMP as a possible
>>>>>>>>>>> option for those worried about security.
>>>>>>>>>>
>>>>>>>>>> I agree that the security section in CORS needs to be improved.
>>>>>>>>>>
>>>>>>>>>> As for the "should CORS exist" discussion, I'll bow out of those until
>>>>>>>>>> we're starting to move towards officially adopting a WG decision one
>>>>>>>>>> way or another, or genuinely new information is provided which would
>>>>>>>>>> affect such a decision (for the record, I don't think I've seen any
>>>>>>>>>> new information provided since last fall's TPAC).
>>>>>>>>>
>>>>>>>>> A smart guy once told me that "You can't tell people anything",
>>>>>>>>> meaning they have to experience it for themselves before they really
>>>>>>>>> get it. Has Mozilla tried to build anything non-trivial using CORS
>>>>>>>>> where cookies + Origin are the access control mechanism? If so, I'll
>>>>>>>>> do a security review of it and we'll see what we learn.
>>>>>>>>
>>>>>>>> Not to my knowledge, no. I believe we use CORS for tinderboxpushlog
>>>>>>>> [1], however since that is only dealing with public data I don't
>>>>>>>> believe it uses cookies or Origin headers.
>>>>>>>
>>>>>>> Does anyone have something?
>>>>>>
>>>>>> At the risk of getting myself involved in this discussion again, you
>>>>>> might consider doing a security analysis of Facebook Chat.  Although
>>>>>> Facebook Chat uses postMessage, it uses both cookies and postMessage's
>>>>>> origin property for authentication, so it might be a system of the
>>>>>> kind you're interested in analyzing.
>>>>>>
>>>>>
>>>>> I think (although I'm not certain) that Tyler is asking partially to
>>>>> figure out where a non-anonymous CORS request is used in the real
>>>>> world. If he isn't, then I am :)
>>>>>
>>>>> Given that a major (but not the only) claim of the need to adopt CORS
>>>>> with support for cookies and the Origin header is that it is in fact
>>>>> already implemented and shipping, it would be good to see how it's
>>>>> being used. If we can't find any examples of it being used (in the
>>>>> non-anonymous case, at least), then the argument against us having to
>>>>> keep it would hold less water. If we can find it being used, then we
>>>>> can see both how we would handle the case with UMP, and whether or not
>>>>> the CORS usage is in fact secure.
>>>>
>>>> Oh, I misunderstood.  I thought he wanted to do a security review to
>>>> show that there was a confused deputy causing problems.
>>>
>>> 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.

-- Dirk

Received on Thursday, 13 May 2010 00:36:55 UTC