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

Re: [cors] unaddressed security concerns

From: Doug Schepers <schepers@w3.org>
Date: Thu, 22 Oct 2009 18:12:43 -0400
Message-ID: <4AE0D8DB.8010408@w3.org>
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.

-Doug Schepers
W3C Team Contact, SVG and WebApps WGs
Received on Thursday, 22 October 2009 22:13:00 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:20 UTC