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

RE: CORS and CSRF protection

From: Hill, Brad <bhill@paypal.com>
Date: Fri, 4 Apr 2014 17:15:47 +0000
To: Monsur Hossain <monsur@gmail.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
Message-ID: <370C9BEB4DD6154FA963E2F79ADC6F2E35C05AC3@DEN-EXDDA-S12.corp.ebay.com>
Any resource that accepts simple requests to do anything but read operations needs CSRF protection of some kind, whether CORS headers are sent or not.

You can use the Origin header as a weak anti-CSRF measure, or you can use a cryptographically strong token in a pattern like OAuth for multi-server scenarios.

We didn't recommend relying on the Origin header because that guarantee depends on all other user agents in your client ecosystem refusing to allow spoofing of that header, and that's not as good of a guarantee, and not under your direct engineering control, compared to using a cryptographically un-guessable explicit capability handle.

From: Monsur Hossain [mailto:monsur@gmail.com]
Sent: Friday, April 04, 2014 7:13 AM
To: public-webappsec@w3.org
Subject: CORS and CSRF protection

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?

Received on Friday, 4 April 2014 17:16:16 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:38 UTC