Re: CORS and CSRF protection

Thanks, I'll take this to a different list. I asked here because the CORS
spec itself recommends CSRF protection, so I was curious if the spec
authors had something in mind.

Thanks!
Monsur



On Wed, Jul 16, 2014 at 6: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
> >>
> >>
> >
>