Generating Crime Safe CSRF Tokens
blog.hboeck.de
Generating Crime Safe CSRF Tokens
1–8 of 8 posts
Re: Generating Crime Safe CSRF Tokens
#2.
Re: Generating Crime Safe CSRF Tokens
#3.
Some people like their sites to work with out javascript.
Re: Generating Crime Safe CSRF Tokens
#4.
CSRF itself is nothing new. What's different here is a discussion of CSRF-generation techniques that are immune to CRIME and BEAST attacks (which are two related, somewhat unpatchable cryptographic attacks that exploits compression to leak information using a chosen-plaintext attack), which is not something people often talk about.
Re: Generating Crime Safe CSRF Tokens
#5.
Some people like their sites to work with out javascript.
> Some people like their sites to work with out javascript.
The 2020 solution to CSRF attacks is using `SameSite` cookies. That makes CSRF tokens obsolete. So if you can accept that old browsers may be vulnerable, you can just use `SameSite` cookies and be done with it.
Re: Generating Crime Safe CSRF Tokens
#6Looking at your PHP example, I was under the impression that random_bytes() was cryptographically secure nowadays, and already generated its pseudorandom sequence non-deterministically?
Can you help me understand why we need to surround the output of random_bytes() if it is already deemed cryptographically secure?
EDIT: Sorry, I have mulled your solution over now and understand that the surrounding detail in the hash is to prevent one form's token being used in a different form. This makes sense, and doesn't imply that random_bytes is deterministic.
Re: Generating Crime Safe CSRF Tokens
#7.
CSRF itself is nothing new. What's different here is a discussion of CSRF-generation techniques that are immune to CRIME and BEAST attacks (which are two related, somewhat unpatchable cryptographic attacks that exploits compression to leak information using a chosen-plaintext attack), which is not something people often talk about.
Another solution is to set the csrf token as two cookies: one that can be read by js via document.cookie, and another that is httponly. Js is then responsible for including the csrf token in any requests (including forms). This avoids crime/breach issues because cookies are part of http headers, which are "compressed" with hpack in http2. Hpack is basically "send it once and reference the last value many times".
Of course there are a few more details to getting this right (such as tying csrf & auth cookies) and it doesn't hurt to also add samesite to the mix.
Re: Generating Crime Safe CSRF Tokens
#8Suggestion: edit the title to capitalize “Crime”.
At first I thought this was about crime, as in police, as in burglary, as in murder, when it’s about CRIME, as in “Compression Ratio Info-leak Made Easy“. And the attack in question is called CRIME, not “Crime”.