- From: David-Sarah Hopwood <david-sarah@jacaranda.org>
- Date: Sat, 24 Oct 2009 07:07:17 +0100
- 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 UTC