Double Submit Cookie Bypass

Question

I am trying to work on an example for my class on how double submit cookie works and how attackers can bypass it

The idea i have is I have two domain att.com and victim.com. The login functionality on victim.com creates the session and also creates a new cookie for csrf protection that will be included in all next requests as a hidden form parameter. I think until now its how double submit works.

For example the cookie that we set was cryptographically not strong, which means its value can be understood by the attacker. In this case the attacker can make request from his own domain to victim.com with form parameters set as required and hidden value set to decoded value.

Is that a correct implementation of bypassing Double submit? The only issue here when a request is generated from attacker.com to victim.com, it does not contain the exact cookie header, rather it contains hidden form value parameter only.

My question here is very simple. If the user is on bad.com and from there we take him to good.com, it won’t include the user cookies in the header, right? So there won’t be any way to bypass it

Answer 1

There seem to be some confusions with regards to the double-submit pattern and cookies in general.

First off, when attacker.com triggers a request to victim.com, the browser may very well include cookies set by victim.com in the request. This depends on the cookie attributes and the specific browser. Modern browsers support the SameSite attribute: None means the cookie will be included in all cross-site requests, Strict means it will never be included in cross-site requests, and Lax sets specific rules for when it should or should not be included. The default (at least in current versions of Firefox and Chromium) is SameSite=Lax. So if an attacker knows the value of the double-submit cookie, and if the browser includes the cookie in cross-site requests (e.g., due to SameSite=None), then the attacker can perform a CSRF attack.

The original idea of the double-submit cookie was to take advantage of the same-origin policy: An attacker running the site attacker.com cannot read or set cookies for the site victim.com. So if victim.com only accepts requests which contain a secret token both as a cookie and a parameter, then the site attacker.com should not be able to perform a CSRF attack against victim.com.

However, there are several ways for bypassing (naive) implementations of the double-submit pattern:

• The attacker may try to guess or predict the cookie value. If this succeeds, and if the double-submit cookie is included in cross-site requests, then the attacker can set the form parameter to the cookie value and perform a CSRF attack. For example, in case the server uses a non-secure random number generator which calculates the cookie values based on known or easy-to-guess data like the current time or the process ID, it can be possible to predict cookie values. To prevent this, the server must use a secure random number generator (like /dev/urandom on Linux) and ensure that the values are sufficiently long (e.g., 128 bits). Additionally, the server should exclude the cookie from cross-site requests by setting the SameSite=Strict attribute.
• Instead of predicting the cookie value, the attacker may be able to capture value through a man-in-the-middle attack, if the server accepts plaintext HTTP traffic. To prevent this, HTTPS must be used consistently, and the double-submit cookie should have a Secure attribute and a __Secure- prefix, so that it will only be transmitted over HTTPS. Note that a CSRF attack with a known cookie value is still only possible in case the double-submit cookie is in fact included in cross-site requests. So SameSite=Strict is again a useful second line of defense.
• If the attacker controls or compromises a subdomain of victim.com, then they may be able to set a double-submit cookie themselves with a value of their choice. For example, if they control attacker.victim.com, they're generally able to create or overwrite cookies for victim.com, allowing them to defeat the CSRF protection. To prevent this, the double-submit cookie should be protected with a message-authentication code (MAC). Calculating a MAC requires a key, so if victim.com keeps their key secret, then an attacker cannot produce a valid double-submit cookie. Additionally, the cookie should have a __Host- prefix. This makes sure that only victim.com can set this cookie, not a subdomain of victim.com. Note that the __Host- prefix also enforces HTTPS, so it can be used instead of the __Secure- prefix mentioned above.