- From: Doug Schepers <schepers@w3.org>
- Date: Thu, 22 Oct 2009 18:12:43 -0400
- To: Maciej Stachowiak <mjs@apple.com>
- CC: "Mark S. Miller" <erights@google.com>, Adam Barth <w3c@adambarth.com>, Anne van Kesteren <annevk@opera.com>, "Henry S. Thompson" <ht@inf.ed.ac.uk>, Jonas Sicking <jonas@sicking.cc>, Arthur Barstow <Art.Barstow@nokia.com>, public-webapps <public-webapps@w3.org>
Hi, Folks- Maciej Stachowiak wrote (on 10/13/09 10:47 PM): > > On Oct 13, 2009, at 5:31 PM, Mark S. Miller wrote: >> >> 2) How well do cross-origin cookies support the simple use cases of >> cross-origin >> resource sharing? >> >> As we all now know, many simple use cases are supported well by >> cross-origin cookies. > > Actually, we now all know that many (most?) simple use cases are not > supported well by cross-origin cookies without some additional mechanism > beyond the basic-pre-existing platform, since they would be subject to a > CSRF vulnerability. You could argue that in the hypothetical world, no > one could have predicted this. But I think at the time cookies were > introduced, no one seriously tried to predict the vulnerabilities. This > was before the same-origin security model was formulated; there was > considerably less understanding of Web security. Cookies first shipped > before JavaScript. > > If CORS has similar vulnerabilities in simple use cases, then in the > non-hypothetical present day we should be able to predict them. 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
Received on Thursday, 22 October 2009 22:13:00 UTC