CSRF: Signed Double Submit Cookie & 'Referer' validation vs MITM and vulnerable subdomains

Question

I have been researching various techniques for preventing CSRF attacks, such as SOP, SameSite, Secure, Referer validation, and CSRF Tokens, and their potential bypasses. During my research, I discovered the following vulnerabilities:

1. A website's subdomain or sibling domain is vulnerable to XSS or HTML Injection. For instance:
   • Subdomain: a.com and vulnerable.a.com
   • Sibling: a.a.com and vulnerable.a.com
2. A subdomain takeover (SDTO) attack
3. A Man-in-the-middle (MITM) attack

However, I'm unsure if correctly implemented Signed Double Submit Cookie and Referer validation are vulnerable to those?

---

What I mean by correctly implemented:

• With Signed Double Submit is meant a session-bound and signed (HMAC) CSRF token, stored in a non-HttpOnly cookie with the Secure flag.
• With Referer validation is meant a Strict (block requests that have no Referer header) and Strong (handles subdomain and URL queries) Referer validation.

---

Questions:

1. Is Signed Double Submit Cookie & Strict & Strong Referer validation vulnerable to MITM?

   According to this SO answer:

   ... If an application is hosted at https://secure.example.com, even if the cookies are set with the secure flag, a man in the middle can force connections to http://secure.example.com and set (overwrite) any arbitrary cookies (even though the secure flag prevents the attacker from reading those cookies)...

   If I read this correctly, this would mean that a MITM can initiate requests from http://b.com to http://a.com, but make the request look like it came from http://a.com. If that is true, then:

   • Signed Double Submit Cookie is vulnerable. The attacker doesn't even need to overwrite the CSRF cookie, since the original one is passed along automatically
   • Strict & Strong Referer validation is vulnerable. The request, even if made from b.com has the value a.com as the Referer value.

2. Is Signed Double Submit Cookie vulnerable to a vulnerable subdomain?
   If an attacker gains access to vulnerable.a.com, they can read and write any cookie.

   Is it true that only cookie prefixes prevent such an attack, or am I missing something where the Signed Double Submit Cookie pattern would prevent this?

3. Is Strict & Strong Referer validation vulnerable to vulnerable subdomain?
   Let's look over some facts:

   • The Referer header is a forbidden header name meaning it cannot be changed programmatically.
   • The session cookie or JWT are commonly protected with the HttpOnly flag, preventing the attacker from reading or writing to it, even on subdomains.

   With that in mind, does this mean that Strict & Strong Referer validation is not vulnerable to vulnerable subdomains?

4. Is OWASP's recommendation false?
   The Signed Double Submit Cookie pattern is categorized as a mitigation technique. The Strict & Strong Referer validation pattern is only categorized as a Defence in Depth (DiD) technique.

   Depending on the above questions, it may seem that only a combination of a Signed Double Submit Cookie and Strict & Strong Referer validation is a true mitigation technique, while alone both are DiD's?

Answer 1

As to 1):

I think you misunderstand the linked paper. What the paragraph says is that naive double-submit cookies can be defeated through a man-in-the-middle attack:

• Scenario 1: The legitimate application is reachable over HTTPS, and the double-submit cookie has the Secure flag set. However, if the client makes a connection over HTTP, then a man-in-the-middle can overwrite the double-submit cookie (not read the existing one) and thereby defeat the protection.
• Scenario 2: The application is reachable over HTTPS, the double-submit cookie has the Secure flag set, and the server enforces HTTPS connections for the primary domain (but not subdomains) through HSTS. If the client makes an HTTP connection to a subdomain, then a man-in-the-middle can still overwrite the double-submit cookie (not read it) through this subdomain.

A double submit cookie with a MAC (or “signed cookie” as you call it) and the Secure flag set does not have this issue. Since the attacker can neither read the current Secure cookie nor calculate the MAC for their own token, they cannot do a classical CSRF attack. However, as soon as plaintext HTTP is used, there are of course all kinds of other issues which may make CSRF completely unnecessary. For example, when a client makes an HTTP request to the target website, the attacker could simply show the log-in form in the response and wait for the client to enter their credentials.

As to 2):

An attacker who controls a subdomain can set cookies for all higher-order domains (except for public suffixes) and make them be sent to all corresponding subdomains, but they cannot read arbitrary cookies. This is why double-submit cookies with a MAC are useful. If the legitimate application at a.com stores an anti-CSRF token with a MAC inside a cookie that has no domain set, then this cookie will not be sent to subdomains. The subdomains can try to set their own anti-CSRF token, but since they're not able to create a valid MAC, the token will be rejected by the server.

As to 3):

If the server checks the exact domain of the referrer, then this validation is not vulnerable to subdomain-based attack. However, there are valid reasons for users to disable the referrer (e. g. to enhance privacy), so you cannot assume it's present.

As to 4):

No, the OWASP recommendations are not false. A double-submit cookies with a MAC and the right properties (empty domain, or cookie prefix) is a good solution. Referrer checks are unreliable, since there may not be a referrer at all. At best, this would be a second line of defense in case the referrer is set.