Re: CORS and CSRF protection

Monsur,

  This isn't really a topic for this list.  I might suggest OWASP or
WASC as groups that can work on practical security patterns.

  By way of a short answer, you are correct that double-submit cookies
are really only appropriate when all valid requests are expected to
come same-origin.  A variety of other patterns are possible.  Some are
based on redirects, such as the one you hypothesize.  There are more
established and well-analyzed versions of such protocols including
OAuth, OAuth2 and SAML you might want to look into.  Another approach
could be to use postMessage() to share a CSRF secret to share scoped,
cross-origin tokens in a purely-client-side implementation.

cheers,

Brad

On Wed, Jul 16, 2014 at 3:06 PM, Monsur Hossain <monsur@gmail.com> wrote:
> 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:
>
> Grab the csrf token from the client's cookie and include its value in the
> query string (or the POST body)
> Make the XHR request with withCredentials set to true, so that the csrf
> token from the api server is also included in the request
> 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) 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
>>
>>
>

Received on Wednesday, 16 July 2014 23:04:30 UTC