Re: UMP / CORS: Implementor Interest

On Wed, May 12, 2010 at 10:39 AM, Ian Hickson <> wrote:
> On Wed, 12 May 2010, Tyler Close wrote:
>> On Tue, May 11, 2010 at 5:15 PM, Ian Hickson <> wrote:
>> > On Tue, 11 May 2010, Tyler Close wrote:
>> >>
>> >> CORS introduces subtle but severe Confused Deputy vulnerabilities
>> >
>> > I don't think everyone is convinced that this is the case.
>> AFAICT, there is consensus that CORS has Confused Deputy
>> vulnerabilities. I can pull up email quotes from almost everyone
>> involved in the conversation.
> There's clearly not complete consensus since at least I disagree.
>> It is also not a question of opinion, but fact. CORS uses ambient
>> authority for access control in 3 party scenarios. CORS is therefore
>> vulnerable to Confused Deputy.
> That's like saying that HTML uses markup and is therefore vulnerable to
> markup injection. It's a vast oversimplification and overstatement of the
> problem.

Is it really? XSS is a major problem. HTML provides no facility for
dealing with XSS and practically invites it. It's hard to deal with
this situation now since HTML is so widely deployed. CORS invites
Confused Deputy problems but is not yet widely deployed. We can still
do something about it.

> It is quite possible to write perfectly safe n-party apps.

It is also quite possible to stand on your head while riding a
bicycle. What's your point? No one has laid out a clear strategy for
developers to follow to use CORS safely and shown how to apply it to
expected use cases. The CORS spec doesn't even mention Confused Deputy

>> > It is certainly possible to mis-use CORS in insecure ways, but then
>> > it's also possible to mis-use UMP in insecure ways.

You could justify any kind of security weakness with that kind of
logic. Nuclear waste can be used in insecure ways, but then so can

>> > As far as I can
>> > tell, confused deputy vulnerabilities only occur with CORS if you use
>> > it in inappropriate ways, such as sharing identifiers amongst
>> > different origins without properly validating that they aren't
>> > spoofing each other.
>> In the general case, including many common cases, doing this validation
>> is not feasible.
> That's nonsense.

We've gone through several scenarios on this list where this
validation is not feasible. On the chromium list, I recently explained
how it is not possible to implement a generic AtomPub client that does
this validation:

Others on this list have agreed that doing this checking is not always possible.

> You have to make sure you don't rely on identifiers to
> confer authority, but that's just a matter of good design.

It's the exact opposite. Using ambient authority with
non-authority-bearing identifiers creates Confuse Deputy


"Waterken News: Capability security on the Web"

Received on Wednesday, 12 May 2010 18:03:31 UTC