Re: UMP / CORS: Implementor Interest

On Wed, May 12, 2010 at 6:33 PM, Ian Hickson <ian@hixie.ch> wrote:
> 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.

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.

There's something very Alice in Wonderland about all this Humpty
Dumpty talk and accusations of nonsense.

If there are special precautions that must be taken to avoid a
problem, then you are vulnerable to that problem. From a security
perspective we are interested in what precautions a technology
requires developers to take and whether or not it's feasible to apply
those precautions. Direct memory management forces C++ developers to
consider what kind of library, technique or verifier they'll use to
protect themselves against memory access errors. Automatic sending of
credentials forces CORS developers to consider how they'll protect
themselves against Confused Deputy problems. The requirement for a
defense is inherent in the design of the tool.

Using UMP you can build an app without use of credentials and so
without needing to consider Confused Deputy 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.

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

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

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

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

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.

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

CORS doesn't even say yet how to use it safely, so what does it mean
to misuse it?

We may also have a different perspective on what it means to be candid
about the problems facing developers.

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

It is also possible to use strcpy() safely, it's just very easy not
to. Same with CORS and Confused Deputy. By only considering the
possible, you conceal real vulnerabilities.

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

What you characterize as inappropriate use or misuse, others consider
to be the natural way to use the Web. Rather than these uses being
wrong, it's possible the CORS security model is wrong.

It will be interesting to see how many Web techniques CORS must
declare to be inappropriate.

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

No, the underlying technology can make it infeasible or just overly
difficult to make safe software.

> 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 design of HTML contributes to those errors by not providing a safe
quoting mechanism.

> 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

The purpose of CORS is to enable doing precisely these things.

> without verifying the data.

And what are the rules for doing that? There's nothing so clear as a
vague idea you haven't written down yet. Verifying that an identifier
is safe to accept from a particular party is non-trivial in CORS.

It's interesting that you are so confident in this without having
built a single application using CORS with credentials.

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

Confused Deputy attacks cannot be fixed by escaping data. There may be
no static test that can be done to validate an identifier. With one
set of ACL entries the identifier may be perfectly valid and in
another it is an attack. This is a different problem than checking for
syntactic errors in an input string.

It is a strange security model that says the client must completely
validate the request before submitting it. It's like a sorting
algorithm that only works on pre-sorted input.

> You have to design your systems from the ground up to be
> secure, but that's nothing new.

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.

--Tyler

-- 
"Waterken News: Capability security on the Web"
http://waterken.sourceforge.net/recent.html

Received on Thursday, 13 May 2010 04:07:26 UTC