Re: CORS and CSRF protection

As a slight aside, I would strongly advise against using the cookie ==
form value approach to preventing cross-site request forgery, since
this opens your application up to a variety of attacks - the most
notable of which is that the attacker can set the XSRF cookie from
within non-secure origins, facilitating attacks on https:// resources.


On Wed, Jul 16, 2014 at 4:04 PM, Brad Hill <hillbrad@gmail.com> wrote:
> 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:35:46 UTC