Re: [cors] unaddressed security concerns

Comments below

On Thu, Oct 22, 2009 at 6:12 PM, Doug Schepers <schepers@w3.org> wrote:

> Let's take it a step further, and propose a worst-case scenario.  Say that
> some undetected hypothetical vulnerability in CORS is discovered some years
> from now, with a degree of severity akin to CSRF.
>
> At that time, we can learn from those new vulnerabilities, and either make
> CORS more secure, or develop a new technology that solves some or all or
> more of the use cases at hand, and discourage the use of CORS (or even block
> the CORS mechanism in servers and clients).
>
> Certainly, some damage will have been done.  Will the damage done be more or
> less than the damage done by less-secure or less-private workaround
> developers employ instead to solve the use cases that CORS is designed for?
>  It's impossible to predict, but it's a real question.
>
> I know that this argument is on the slippery slope towards being a
> slippery-slope argument, but my point is that, through inaction born of
> trepidation toward unknown unknowns, we may cause as much (or more) of a
> security problem than if we act now in a way that seems the most responsible
> course of action, and learn later from our mistakes how to improve the
> situation.
>
> Regards-
> -Doug Schepers
> W3C Team Contact, SVG and WebApps WGs

Thanks for putting the situation in these terms; I like the form of
this analysis, even if am not sure I agree with the conclusion.

The brief summary of the debate is that Mark M is citing Tyler's
argument, and Mark's and Tyler's long experience with this kind of
thing, in predicting that any system with the currently described CORS
architecture will have vulnerabilities. Anne has said, I don't get it,
show me the goods, and rejected a first attempt. It's not clear where
the burden of proof should be; those who care about first about
security will say "convince me the risk is acceptable", while those
who are first trying to get something done will say "convince me that
the risk is unacceptable".

We're not talking about some unknown future vulnerability; we're
talking about a known class of vulnerabilities (CSRF or confused
deputy), and trying to figure out the magnitude of the risk given the
proposed solution. The solution design is untried in distributed
systems and in Javascript, which raises the risk, but there is a
deployed analog, namely the Java security model, that those who like
stack introspection can point to. So the risks are not necessarily
unknowable; it may be that more analytical work is required than
anyone who has been paying attention wants to invest.

It seems OK if the WG's answer is "let's take the risk" as long as
there is a well-articulated rationale similar to the one you give
above. Then the downstream process can sort out whether the W3C brand
should be applied to the solution.

Jonathan

Received on Friday, 23 October 2009 21:04:57 UTC