Re: CORS and CSRF protection

On Fri, Apr 4, 2014 at 12:15 PM, Hill, Brad <bhill@paypal.com> wrote:

>  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.
>

Thanks, this point here helped clear things up for me.


>  *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?
>
>
>
> Thanks,
>
> Monsur
>
>
>