Re: CORS and CSRF protection

Hi there. Sorry to dredge up this old thread, but I'm having trouble
understanding how Double Submit Cookies would work with CORS. Imagine I
have an HTML page at http://client.example.com that makes a CORS POST
request to http://api.example.com. Double Submit Cookies relies on a cookie
and a request parameter having the same value. However, in the case of
CORS, the request originates from http://client.example.com, but the cookie
will be from http://api.example.com.  There is no way for client.example.com
to read api.example.com's cookie and included it in the request. Therefore,
api.example.com needs some mechanism to give client.example.com the value
of the CSRF token.

One way to do this is after logging in to api.example.com, set a random
number in a cookie (separate from the session cookie), and then redirect
the user to a page on client.example.com with the random number in the
query string (for example, client.example.com/signin?csrf_token=12345). The
client would then set its own cookie with the csrf token value. On requests
that require CSRF protection, the client would do the following:

   1. Grab the csrf token from the client's cookie and include its value in
   the query string (or the POST body)
   2. Make the XHR request with withCredentials set to true, so that the
   csrf token from the api server is also included in the request
   3. The server compares the csrf value in the client's query parameter to
   the value in the server's cookie.

However, I am not a security expert, so I have no idea if this is
reasonable. Is there anyone who can help with this?

Thanks,
Monsur


   -



On Fri, Apr 4, 2014 at 9:34 AM, Jim Manico <jim.manico@owasp.org> wrote:

>  I would consider the double-cookie submit defense in this situation.
> Maybe.
>
> From
> https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet
>
> Double Submit Cookies
>
> Double submitting cookies is defined as sending a random value in both a
> cookie and as a request parameter, with the server verifying if the cookie
> value and request value are equal.
>
> When a user authenticates to a site, the site should generate a
> (cryptographically strong) pseudorandom value and set it as a cookie on the
> user's machine separate from the session id. The site does not have to save
> this value in any way. The site should then require every sensitive
> submission to include this random value as a hidden form value (or other
> request parameter) and also as a cookie value. An attacker cannot read any
> data sent from the server or modify cookie values, per the same-origin
> policy. This means that while an attacker can send any value he wants with
> a malicious CSRF request, the attacker will be unable to modify or read the
> value stored in the cookie. Since the cookie value and the request
> parameter or form value must be the same, the attacker will be unable to
> successfully submit a form unless he is able to guess the random CSRF value.
>
> Direct Web Remoting (DWR) <http://directwebremoting.org/> Java library
> version 2.0 has CSRF protection built in as it implements the double cookie
> submission transparently.
>
>
>
> On 4/4/14, 7:12 AM, Monsur Hossain wrote:
>
> 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
>
>
>