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

by

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?

  • Does this answer your question? CSRF Tokens vs Session Cookies

    – 

  • Thanks, @HeikoTheißen. I think that answers my second question, stating that response to the client CRSF token request must contain no Access-Control-Allow-Origin header, causing the fetch to fail.

    – 

  • If the CSRF token was just another cookie, the attacker could cause the victim’s browser to (1) obtain the CSRF cookie and (2) use it in a subsequent request, because the attacker need only trigger the requests, not look at their response. (In reality, it is more complicated, see developer.mozilla.org/en-US/docs/Web/HTTP/Headers/…)

    – 




  • I understand that the server must not use the presence of a CSRF token in a cookie to validate the request – but I don’t understand why the server can’t deliver it to the client with a Set-Cookie response header as seems to be recommended for the Double Submit Cookie pattern. (“In a nutshell, an attacker is unable to access the cookie value during a cross-site request. This prevents them from including a matching value in the hidden form value or as a request parameter/header.”)

    – 

  • With the double submit cookie pattern, the token is received as a cookie but resubmitted in a form field. The vulnerability from my previous comment occurs if the token is both received and resubmitted as a cookie.

    – 

Leave a Comment