- From: Tyler Close <tyler.close@gmail.com>
- Date: Wed, 12 May 2010 12:26:29 -0700
- To: Jonas Sicking <jonas@sicking.cc>
- 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>
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:27:02 UTC