Re: UMP / CORS: Implementor Interest

On Wed, 12 May 2010, Tyler Close wrote:
> >
> >> 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.

HTML's use of markup is not a vulnerability.
CORS's use of ambient authority is not a vulnerability.

Sure, both can be used in vulnerable ways, but they are not themselves 
vulnerabilities.


> > 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?

My point is that you are arguing that one design is less good than 
another, but you are using words that make it sound like you are arguing 
that one design is actually intrinsicly vulnerable. It's just as possible 
to make bad designs using UMP than with CORS. (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.)


> 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.

What use cases would you like examples for? Let's write them up and give 
them to Anne to the introduction section.


> The CORS spec doesn't even mention Confused Deputy problems.

I'm sure Anne would be happy to include suitable text if you provide it. 
However, such text has to be accurate, and not make false claims like 
saying that there is a security vulnerability where there is only the 
potential for one when the feature is misused.


> >> > 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 hammers.

No. There is a _massive_ difference between features that _may_ be 
misused, and features that _cannot be used safely_. For example, if XHR 
let you read data from any site without any sort of server opt-in, that 
would be a real security vulnerability, and could not be defended by 
saying "it's possible to mis-use it". It is possible to use CORS safely.


> 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:
> 
> http://groups.google.com/a/chromium.org/group/chromium-dev/msg/afda9a4d1d1a4fcb

I don't think using AtomPub is necessarily a good idea. AtomPub was not 
designed for use with CORS. If you're going to use technologies 
inappropriately then sure, you'll have security problems.


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

It's possible to design systems that can't be made secure, whether using 
CORS or UMP. But there the vulnerability is with that software, not with 
the underlying technology.


On Wed, 12 May 2010, Dirk Pranke wrote:
> >
> > There's clearly not complete consensus since at least I disagree.
> 
> I'm trying to understand what you mean by this. Are you saying that CORS 
> doesn't ever have Confused Deputy vulnerabilities? Or that it didn't 
> create new ones? Or that the vulnerabilities exist but aren't "subtle 
> but severe"?

I'm saying that CORS doesn't ever have Confused Deputy vulnerabilities, 
it's software that misuses CORS that has them; just like HTML doesn't ever 
have markup injection vulnerabilities, it's the software that embeds user 
content without verifying it that has those.

The guidelines for not falling prey to these attacks with CORS are pretty 
simple: don't do things on behalf of other origins, or include data from 
other origins without verifying the data. It's actually the same 
conceptual problem as markup injection -- you have to validate the data 
that you're given (e.g. escaping it) before infusing it with your 
authority. You have to design your systems from the ground up to be 
secure, but that's nothing new.

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

Received on Thursday, 13 May 2010 01:56:42 UTC