Re: UMP / CORS: Implementor Interest

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.


Cheers
devdatta



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