CookieCsrfTokenRepository allows the client to create its own Csrf Tokens

Question

CookieCsrfTokenRepository sets a cookie and on subsequent requests it just just compares the cookie value from the client with the cookie value from the header.

It does not remember if it is still the value it set on first time. It just compares them.

But the angular docs (https://angular.io/guide/http#security-xsrf-protection) say "The token must be unique for each user and must be verifiable by the server; this prevents the client from making up its own tokens. Set the token to a digest of your site's authentication cookie with a salt for added security."

So is CookieCsrfTokenRepository insecure?

Answer 1

The CookieCsrfTokenRepository is similar to the "double-submit cookie" pattern described by the OWASP CSRF Prevention Cheatsheet. While similar, it isn't strictly the double-submit pattern, as the associated CsrfFilter does't require that the token be "double-submitted". The filter will happily accept the CSRF token transimtted via the cookie whtn validating a request, as opposed to requiring that the token be double-submitted as a request parameter and then comparing the parameter to the cookie. As such, I assume the technique relies on the CSRF token cookie setting the SameSite=Strict attribute to prevent CSRF.

To answer your question, the CookieCsrfTokenRepository is vulnerable to "cookie-fixation", if an attacker is able to set the CSRF cookie value. An attacker might achieve this by (ref):

• Exploiting a sub-domain.
• Man-in-the-middle attack on the HTTP connection.

The risk/feasibilty of the above depends on your application configuration.

The cookie-based CSRF mitigation approach can be hardened in various ways:

• HTTP Strict Transport Security (HSTS) - to prevent man-in-the-middle attacks.
• Cookie Prefixes (“__Host-” is the one you want) - to prevent sub-domains from setting the CSRF token cookie.
• Sign the token (with a private-key or secret known only to the server)
• Bind the token to the user or session (e.g. use an HMAC of the current session id).
• Use a custom HTTP header, if your application makes use of AJAX requests.

The OWASP CSRF Prevention Cheat Sheet (linked above) provides a nice summary of CSRF prevention approaches and tradeoffs.