improving csrf prevention
In reading about the CRIME attack and another post I thought about how this affects cross site request forgery tokens_Prevention_Cheat_Sheet) (or anti-CSRF tokens I guess). The spark really came from the second Tor blog post.
regular csrf
There are a couple ways to compute csrf tokens, but the general outline is something like hmac(sitesecret, user + action)
. Then the server can verify the token in the POST by computing the hmac a second time. Only the server knows the sitesecret, so bad people cannot compute the hmac. Tying the csrf token to the user is required to prevent me from signing in and using my token with your account. It’s tied to the action to prevent a mistake on one page that reveals a harmless action token from giving away an important token. And you want to use hmac (and probably also some separator character between user and action) to prevent people from doing silly things like creating accounts named “tedudeleteaccountok”.
the crime attack
Standard practice is to compress HTTP bodies. That’s how we make the internet fast, right? So what happens if we (as the attacker) make somebody request the same page over and over, but with slightly different data that we control? Like a webmail compose form, where we can prefill the subject line by appending subject=xyz to the request? If our subject is the same as the csrf token, the page will compress a lot, if it’s different then it will compress slightly less. This is same attack as on TLS compression, except now the secret we are after lives in the HTML body too, and even HTTP compression is enough to reveal it.
prevention
Change the csrf generation to include a random secret every time, and add that to the document. Basically, you have hmac(sitesecret + randomsecret, user + action)
. The server doesn’t keep the randomsecret, it adds it to the form as a second hidden parameter. This is in contradiction to the OWASP guidelines above, which recommend only generating one csrf token per session. In order to prevent the attack, we have to make sure it changes on every form. Now, even if the attacker can observe many requests, the length of the compressed responses will vary.
or
Disable compression.
Tagged: programming security software web