Re: UMP / CORS: Implementor Interest

On Wed, 12 May 2010, Tyler Close wrote:
>
> So HTML is not vulnerable to Cross-Site Scripting, C++ is not vulnerable 
> to buffer overflows and so CORS is not vulnerable to Confused Deputy.

Correct.


> As explained above, CORS with credentials is intrinsically vulnerable to 
> Confused Deputy. The use of credentials forces the developer to consider 
> Confused Deputy vulnerabilities.

You are using the word "vulnerable" in a manner inconsistent with its 
meaning in the Web standards community.


> > It's just as possible to make bad designs using UMP than with CORS.
> 
> It's rare that a tool makes bad design impossible. Are you saying that's 
> the metric for comparing the security of two tools? So long as bad 
> design is possible, the two tools are equivalent?

You seem to be arguing that as long as bad design is possible, a tool 
shouldn't be made available at all! [1]

[1] http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/0604.html


> > (I would argue that UMP actually makes it more likely that designs 
> > will have poor security characteristics since it ends up being easier 
> > to ask for the user's credentials directly than doing the right thing. 
> > With CORS, on the other hand, it's easier to use the user's existing 
> > session, so it's less likely that people will ask for credentials 
> > inappropriately.)
> 
> But you haven't considered the dangers that come from reusing the user's 
> existing session. That's an inherently dangerous thing to do, but you 
> seem to ignore the problem and so come to the conclusion you want.

It is not an inherently dangerous thing to do, that's hyperbole. It is 
certainly possible to use this tool wrongly, e.g. by executing actions on 
the behalf of another origin, but is anyone suggesting doing that?

It would be helpful if we could focus on concrete use cases, so that we 
could document them and add offer them to Anne to add to the CORS spec.


> > What use cases would you like examples for? Let's write them up and 
> > give them to Anne to the introduction section.
> 
> I want to see CORS try to develop something like the Security 
> Considerations section in UMP with simple, clear choices for application 
> developers to consider. I want this advice to be feasible to follow and 
> to provide a robust defense against Confuse Deputy problems. I doubt 
> such advice can be provided for CORS.

I'm interested in providing authors with concrete examples based on 
real-world use cases. What use cases are you concerned about? I see no use 
cases in the section to which you refer, only abstract advice:

   http://dev.w3.org/2006/waf/UMP/#security


> Confused Deputy attacks cannot be fixed by escaping data. There may be 
> no static test that can be done to validate an identifier.

Then don't use identifiers of this nature.


> It is a strange security model that says the client must completely 
> validate the request before submitting it.

It's how all the technologies on the Web so far have been secured. While 
it may be academically strange, it is the only security model Web authors 
are familiar with, so to them it isn't strange at all. XSS, XSRF, SQL 
injection -- all these classes of problems are addressed by validating 
data in the request before acting on it or passing it on to the next 
system. You may not like this kind of design, but it's what authors are 
most used to.


> Yes, well, that's what I'm trying to do. By refusing to admit that tools 
> contribute to bugs in any way, you are doing the opposite.

To be blunt: browser vendors have said they are implementing CORS, and 
that UMP isn't enough. Continuing to argue against this isn't working. If 
you want CORS replaced with something else, you need to find something 
that will convince browser vendors; repeating your claims that the CORS 
technology is vulnerable is merely distancing you further from the rest of 
the working group and is more likely to make any further advice you may 
have get ignored as well.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Thursday, 13 May 2010 05:02:29 UTC