W3C home > Mailing lists > Public > public-webappsec@w3.org > April 2014

CORS and CSRF protection

From: Monsur Hossain <monsur@gmail.com>
Date: Fri, 4 Apr 2014 09:12:46 -0500
Message-ID: <CAKSyWQmUF0t-QO4xnnoAxjR07E-fnqH90L0vPHQPG8dPLZmOnA@mail.gmail.com>
To: "public-webappsec@w3.org" <public-webappsec@w3.org>
I have a question about this statement in section 4 of the CORS spec,
regarding credentialed simple requests:

"...resources for which simple requests have significance other than
retrieval must protect themselves from Cross-Site Request Forgery (CSRF) by
requiring the inclusion of an unguessable token in the explicitly provided
content of the request."


Does this mean that CSRF protection should be added in order to protect
resources from non-CORS requests (e.g. requests without an Origin header,
such as JavaScript form.submit()), or does it mean that CSRF protection
should be used for all requests (CORS as well as non-CORS)?

If the recommendation is that CSRF protection should be used on CORS
requests, it raises a few more questions:

1) What protections does CSRF protection add vs validating the Origin
header? Both are tokens from the client that can't be spoofed (in the CSRF
case, it is an unguessable token, in the Origin case, the origin is a known
value, but it can't be overridden by malicious clients)

2) The details of implementing CSRF protection for any cross-origin request
seems difficult, at least if you are trying to coordinate a CSRF token
across two different servers. The servers need to coordinate a shared
secret in order to generate a CSRF token from the client and parse the same
CSRF token on the server. Its not as simple as downloading a CSRF package
from GitHub and adding it to your server. Is that correct, or am I missing
something?

Thanks,
Monsur
Received on Friday, 4 April 2014 14:13:15 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:05 UTC