Hi Jonathan, I was one of the people who complained a long time ago about the dangers of sending cookies with cross-site requests, but the WG responded to my concerns and now I'm satisfied with the spec as it stands today.
CORS requires servers to explicitly add a new HTTP header
(Access-Control-Allow-Credentials:true) to the response before credentials
(cookies) to be sent from browser to a (cross-site) server. If this header
is not included, then CORS-conformant browsers will not send cookies. This
approach helps to minimize the chance that unsophisticated server
developers (who are uninformed about CSRF protection) might introduce new
vulnerabilities as they open up their sites to cross-site requests because
the default is that credentials are not sent.
While the Access-Control-Allow-Credential header helps to minimize CSRF
vulnerabilities in the face of CORS, it doesn't represent a complete
solution to CSRF problems. Servers that enable cross-site requests with
credentials around sensitive information should include appropriate CSRF
bulletproofing, such as using random session-specific tokens (not stored in
cookies) to ensure that cross-site requests are coming from properly
authenticated users who are involved in properly managed sessions.
While it is impossible to be certain about the security implications of
CORS, which represents a major enhancement to the Web communications, it
looks to me that the potential CSRF problems have been addressed in an
adequate manner, at least to the same level as existing same-site XHR
requests. Servers have to opt-in for credentials to be sent. Once they
opt-in, then the same CSRF bulletproofing techniques that are required for
same-site XHR requests could be used to safeguard cross-site XHR requests.
Jon
|------------>
| From: |
|------------>
>-----------------------------------------------------------------------------------------------------------------------------------------|
|Jonathan Rees <j...@creativecommons.org>
|
>-----------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| To: |
|------------>
>-----------------------------------------------------------------------------------------------------------------------------------------|
|Doug Schepers <schep...@w3.org>
|
>-----------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Cc: |
|------------>
>-----------------------------------------------------------------------------------------------------------------------------------------|
|Maciej Stachowiak <m...@apple.com>, "Mark S. Miller" <erig...@google.com>,
Adam Barth <w...@adambarth.com>, Anne van Kesteren |
|<ann...@opera.com>, "Henry S. Thompson" <h...@inf.ed.ac.uk>, Jonas Sicking
<jo...@sicking.cc>, Arthur Barstow <art.bars...@nokia.com>, |
|public-webapps <public-webapps@w3.org>
|
>-----------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Date: |
|------------>
>-----------------------------------------------------------------------------------------------------------------------------------------|
|10/23/2009 02:06 PM
|
>-----------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Subject: |
|------------>
>-----------------------------------------------------------------------------------------------------------------------------------------|
|Re: [cors] unaddressed security concerns
|
>-----------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Sent by: |
|------------>
>-----------------------------------------------------------------------------------------------------------------------------------------|
|public-webapps-requ...@w3.org
|
>-----------------------------------------------------------------------------------------------------------------------------------------|
Comments below
On Thu, Oct 22, 2009 at 6:12 PM, Doug Schepers <schep...@w3.org> wrote:
> 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
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.
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".
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. 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.
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. Then the downstream process can sort out whether the W3C brand
should be applied to the solution.
Jonathan
<<inline: graycol.gif>>
<<inline: ecblank.gif>>
