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

Re: UMP / CORS: Implementor Interest

From: Devdatta <dev.akhawe@gmail.com>
Date: Wed, 12 May 2010 12:38:20 -0700
Message-ID: <AANLkTilOwMDwikyrgU8IyJ7C9-sq4uvkAonlm1t6a1_N@mail.gmail.com>
To: Tyler Close <tyler.close@gmail.com>
Cc: Jonas Sicking <jonas@sicking.cc>, Ian Hickson <ian@hixie.ch>, Arthur Barstow <Art.Barstow@nokia.com>, Anne van Kesteren <annevk@opera.com>, public-webapps <public-webapps@w3.org>, Adam Barth <w3c@adambarth.com>
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


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.


On 12 May 2010 12:26, Tyler Close <tyler.close@gmail.com> wrote:
> On Wed, May 12, 2010 at 11:17 AM, Jonas Sicking <jonas@sicking.cc> wrote:
>> On Wed, May 12, 2010 at 9:01 AM, Tyler Close <tyler.close@gmail.com> wrote:
>>> On Tue, May 11, 2010 at 5:15 PM, Ian Hickson <ian@hixie.ch> 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.
>>> 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.
>> First I should note that I have no idea what this argument is trying
>> to result in. Is this an attempt at preventing CORS from going to REC?
>> Or are we just rat holing old discussions?
>> That said, I feel like I don't want to let the above claim go
>> unanswered. Like Ian, I think you are oversimplifying the situation. I
>> would argue that UMP risks resulting in the same confused deputy
>> problems as CORS in the same complex scenarios where CORS risks
>> confused deputy problems.
>> With an UMP based web application it seems like a big risk that people
>> will create APIs like:
>> function fetchResource(uri, successCallback) {
>>  req = new UMPOrWhateverWellCallItRequest();
>>  uri += "&securityToken=" + gSecurityToken;
>>  req.open("GET", uri);
>>  req.send();
>>  req.onload = function() { successCallback(req.responseText) };
>> }
>> Such code risks suffering from the exact same confused deputy problems
>> as CORS.
> To paraphrase: "Developers might build something that is broken in the
> following way; therefore, we should give them something that is
> already broken in that way."
>> My concern with UMP is that it takes no responsibility for
>> the security model and instead puts all responsibility on web sites.
> The UMP spec does go to significant lengths to show developers how to
> do things the right way and why. The Security Considerations section
> provides a straightforward model for safely using UMP. CORS has
> nothing similar.
>> I'm not convinced this will result in increased security on the web,
>> just the ability for UAs to hide behind arguments like "it's not our
>> fault that the website has a bug".
> The best we can do is provide good tools and show people how to use
> them. CORS is a tool with known problems and no instructions on safe
> use.
>> I don't see why we couldn't just give websites the ability to use
>> either security model and stop wasting time reiterating old
>> discussions.
> I just don't understand why we want to deploy a broken security model.
> --Tyler
> --
> "Waterken News: Capability security on the Web"
> http://waterken.sourceforge.net/recent.html
Received on Wednesday, 12 May 2010 19:39:15 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 13:55:34 UTC