W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2009

Re: [cors] unaddressed security concerns

From: David-Sarah Hopwood <david-sarah@jacaranda.org>
Date: Sat, 24 Oct 2009 07:07:17 +0100
Message-ID: <4AE29995.6030504@jacaranda.org>
To: public-webapps@w3.org
Doug Schepers wrote:
> Jonathan Rees wrote (on 10/23/09 5:04 PM):
>>
>> 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.

The specific risk is quite clear: it's the risk of CSRF attacks that
are currently prevented (or mitigated) by the same-origin policy.
These won't be prevented or mitigated to the same extent by browsers
that implement CORS.

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

This is part of the disconnect I've seen in previous discussions in
the list archives. There doesn't need to be a "specific attack vector to
which CORS is vulnerable", in order for the adoption of CORS to lead to
more, and more serious, CSRF attacks.

CSRF vulnerabilities are a consequence of the fact that authorizing
information -- such as cookies, HTTP-auth credentials, and use of client
certificates -- is sent implicitly in requests, even as a result of actions
by an attacker who does not have that information. (The attacker is also
able to influence part of the request in many cases.)

Such implicit use of authorizing information is called "ambient authority"
by the capabilities community.

Currently, the prevalence and impact of CSRF attacks is limited to some
extent by the same-origin restrictions. The adoption of CORS will remove
part of that limitation. This should be expected to result in more sites
that rely on CORS being vulnerable to CSRF, even though the vulnerabilities
are dependent on the detailed behaviour of those sites and are not a
*direct* consequence of CORS per se. That is, these sites could in principle
avoid such attacks, but only by avoiding the use of ambient authority, and
we know from experience that some proportion of them won't do that.

-- 
David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com
Received on Saturday, 24 October 2009 06:07:56 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:34 GMT