Update: [CSRF] Reintroduce an overview of Double Submit Cookie with HMAC

[advename]

What is missing or needs to be updated?

The Double Submit Cookie is a very popular technique. Searching the web for CSRF mitigation techniques, nearly all sources points to the OWASP CSRF Cheatsheet page. Unfortunately, unless the Double Submit Cookie technique uses signed and session bound tokens, with e.g. HMAC, it is vulnerable (to my knowledge) to:

• Session Hijacking, a type of MIT attack
• Vulnerable subdomains or sibling domains (XSS or HTML injection)

(Reference: 1, 2)

However, this has led over the past years to a range of different (mis-)implementations of the HMAC Double Submit Cookie technique, due to the fact of the lack of knowledge of what value exists for what reason. I've commonly seen that the CSRF Token is generated with HMAC using a mix of the following values:

1. A time-to-live (TTL) timestamp, creating short-lived tokens
2. A session ID, binding the token to the session
3. A static unique user value, such as the user id or email address
4. A nonce, to add additional randomness to the token

For example, this GO CSRF package uses a combination of 1 & 3, but lacks the important 2.

I would imagine that these mis-implementation originated from an old version of the OWASP CSRF page, recommending to use "user's ID, a timestamp value and a nonce".

After extensive research, I've come to the conclusion that to effectively prevent the above-mentioned vulnerabilities, the HMAC should be built with at least:

• Session or request bound values, that changes for each login session or each request (1 | 2 | 3). There's also a great SO answer that doubts the Token per request that can harm user experience without much added security.
• A Nonce for anti-collision purposes. A random value (not required to be cryptographical random, but preferred) to ensure that successive calls in the same second don't produce the same hash (1)

Note
It's a common misconception to include timestamps as a value to specify the CSRF token Time-to-live (TTL). A CSRF Token is not an access token. They are used to verify the authenticity of requests throughout a session, using session information. A new session should generate a new token.
Source: https://stackoverflow.com/a/30539335

How should this be resolved?

I'd like to suggest to re-introduce the overview of the Double Submit Cookie with HMAC with implementation details, without being platform-specific.

[mackowski]

@advename awesome issue, thanks for it. It looks good for me after the first read but I need to dive deeper into this.
@jmanico what do you think about this change?

[kwwall]

My only comment would be on the statement: *A Nonce for anti-collision purposes.* A random value (not required to be cryptographical random, but preferred) to ensure that successive calls in the same second don't produce the same hash. Nonce are generally used to prevent replay attacks, not as mechanism to prevent collisions. If the username is part of the HMAC'd data and the usernames are unique, that should be sufficient to prevent collisions (or, username & client's IO address [WIYTM?]), but not to prevent replay attacks. But nonce stands for "number used once" and you MUST ensure that. The typical approaches is pick a something monotonically increasing (e.g., a timestamp in nanoseconds) or use a CSRNG to pick a large random #, say at least 128 bits or so. If you use that strategy, you generally are safe and don't need to remember all the previous nonce values from forever. For almost anything else you do. Regular PRNGs usually have (long) cycles and you need to be careful about your hardware clock getting rolled back (is that in your threat model?). Any that is all I wanted to say...just state nonce are used to prevent replay attacks, not to prevent collisions It's late and I've rambled on enough. Just be thankful that it's not noon and I'm sitting in front of a keyboard rather than typing this out on my phone close to 2am. 😜

…

-kevin

On Wed, Apr 5, 2023, 12:31 PM mackowski ***@***.***> wrote: @advename <https://github.com/advename> awesome issue, thanks for it. It looks good for me after the first read but I need to dive deeper into this. @jmanico <https://github.com/jmanico> what do you think about this change? — Reply to this email directly, view it on GitHub <#1110 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAO6PG46JVUS7T4CJWXIHGTW7WM6PANCNFSM6AAAAAAWQHEOGY> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[advename]

@kwwall

Alright - I'll try to keep in mind what "nonce" is used for in the future :)

That said, I'd rather go with the CSPRNG in this case, as I'm trying to remove the idea of timestamps entirely and thereby prevent confusion.

And i hope it was a great night, that made you stay up till 2AM ;)

[kwwall]

@advename - I'd prefer to recommend CSPRNG as well. You seldom will go wrong that way.

Regarding 2am nights, those ended on 4/13 when I finally got ESAPI 2.5.2.0 out the door.

[advename]

@mackowski, I believe this issue and #1111 are related. Should we solve both within this issue?

[advename]

Moreover, I thought about introducing the term "Naive Double Submit Cookie" to make the patterns more distinctive:

• "Double Submit Cookie"
  • "Naive Double Submit Cookie" (Double submit cookie without any signing or session-dependent value)
  • "Session-dependent signed Double Submit Cookie"
    • "HMAC CSRF Token" (Explain the correct concept and show a pseudocode example)