cookiescsrfowasp

Cross-Site Request Forgery Prevention: using a cookie for the Synchronizer Token Pattern

The OWASP description of the Synchronizer Token Pattern for CSRF Prevention (here) states:

For the Synchronised Token Pattern, CSRF tokens should not be transmitted using cookies.

My understanding is that this is referring to the transmission of the CSRF token from the server to the client. (I understand that the CSRF token must be sent from client to server in a hidden form field or custom header value.)

What would be the security risk of using a cookie for transmission of the CSRF token from server to client?

The OWASP cheat sheet goes on to say:

The CSRF token can be transmitted to the client as part of a response payload, such as a HTML or JSON response.

If the server only validates the session ID (determined by the presence of a session cookie) when responding to a client request for the CSRF token, surely this would completely bypass the protection as an attacker could make a cross-site request to retrieve the CSRF token before sending it to validate a subsequent request?

Solution

  • From my discussion with Heiko (thanks), I've concluded:

    1. The synchronizer token pattern discourages the use of a cookie to send the CSRF token from server to cookie because there's no particular reason to use a cookie, but there are potential disadvantages:

      • Having the token in a cookie would result in it being sent with every request, increasing the risk that it is leaked.
      • An incorrect server implementation checking for the presence of the CSRF token in the cookie would completely undermine the mechanism. (The server must check for the CRSF token in the request body or a custom header.)

    2. Cross-origin resource sharing (CORS) prevents an attacker from requesting the CRSF token. CORS provides additional protection, prohibiting the sending of credentials (e.g. session cookie) if the server sets an Access-Control-Allow-Origin: * header.