Re: [cors] unaddressed security concerns

Hi, Jonathan-

Jonathan Rees wrote (on 10/23/09 5:04 PM):
>
> 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.

Thanks, I hope it helped.


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

I see the situation differently.  I don't hear the CORS proponents 
saying, "convince me the risk is unacceptable", I hear them saying, 
"prove that there is a risk".  These are quite different statements.

Adam seems to be arguing that there is no known risk, and I have not 
heard a concrete argument from Mark or Tyler that detailed the specific 
risk, only that, based on their (admitted) experience, they anticipate 
that a risk may arise.


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

Mark has drawn an analogy to CSRF, but I don't believe he's actually 
stated a specific attack vector to which CORS is vulnerable.  Perhaps 
I've misunderstood?

I'm not at all a security expert, or even particularly well-informed on 
the topic, but it does occur to me that most of CORS' opponents seem 
very much in the capability-based security camp [1], and may distrust or 
dislike something more "authentication-based" like CORS.  Perhaps this 
is more a culture clash than an identification of a known problem?  Just 
speculation on my part...


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

That's an interesting point... if the proponents or opponents of CORS 
did more testing and modeling, would that satisfy concerns?  Surely it 
couldn't be hard to set up a few common model architectures using CORS 
and announce them as targets for the white hat community?

Mind you, I'm not stating one way or the other that this should be part 
of the exit criteria for CORS, just that it would be helpful overall, 
and frankly, if it hasn't been tried, I'm a little surprised... isn't 
this *exactly* the sort of thing Google, MS, the browser vendors, and 
the security community at large have the resources and expertise to do, 
as well as the incentive?  Can a brother get a honeypot?

Having suggested it, I admit some reluctance toward the idea... if no 
vulnerability is readily found, it doesn't prove it's secure, just that 
an insecurity hasn't been found yet, and so the fact of its security can 
never be proved, only disproved.  I don't want to delay the spec without 
some substantive evidence.


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

I think there are several answers, which seem to appeal differently to 
different audiences.


> Then the downstream process can sort out whether the W3C brand
> should be applied to the solution.

I wasn't quite sure what this means, but I interpreted it as, "over the 
course of time, after implementations in CR phase, we can determine if 
this should be a W3C Recommendation."  Indeed, the proof of the pudding 
should be in the testing.


[1] http://en.wikipedia.org/wiki/Capability-based_security

Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs

Received on Saturday, 24 October 2009 00:30:19 UTC