What possible vulnerabilities exist for dual submitted CSRF tokens (cookie and form field)?

Question

In this question (CSRF cookie vs session based tokens), folks recommend against storing the CSRF token in a cookie, saying that storing it in the session server-side is more secure. What vulnerability exists for storing the token in a cookie as well as in a form field, then confirming these match server side when processing the POST?

Answer 1

A) Token as a hidden field and token in the cookie

OWASP points out to some vulnerabilities:

CSRF tokens should not be transmitted using cookies

... CSRF tokens in GET requests are potentially leaked at several locations, such as the browser history, log files, network appliances that log the first line of an HTTP request...

B) Token as a hidden field and token ins the session

This approach is called also Synchronizer Token Pattern. It has no inherent vulnerabilities. But nevertheless there can be some problems:

• This works well if you use form submit, because there are no any efforts needed on the client. Browser will just send all the fields in the form including the token. But nowdays more often AJAX is used. There are no fields that will be sent implicitly. Also there is no trivial way to set such a field on the server side. That's why you need some efforts to transfer the token from the server to the client, to make sure that the client has an up to date token (in case you refresh it with each request), to send this token within each unsafe/modifying request to the server. Check, if the client framework that you use has built-in CSRF protection.
• This approach is not applicable if the server is stateless.

C) Consider other solutions

The OWASP web site recommends different approaches to implement CSRF protection. One of the is SameSite. The answer you refer was posted in 2012. The SameSite attribute was introduced in 2016. That's why the state,statement in the answer that browser automatically sends all cookies is not quite correct. It depends on the SameSite attribute. SameSite is easy to use, it does not need any code on the client side. But it protects only if you control the subdomains. See further protection principles on the OWASP web site.