Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
CSRF token mask from breach-mitigation-rails gem #16570
This merges in the code from the breach-mitigation-rails gem that masks authenticity tokens on each request by XORing them with a random set of bytes. The masking is used to make it impossible for an attacker to steal a CSRF token from an SSL session by using techniques like the BREACH attack.
The patch is pretty simple - I've copied over the relevant code and updated the tests to pass, mostly by adjusting stubs and mocks. @NZKoz suggested that this would be a useful thing to have in Rails itself - we (and many others) have been using it in production for over a year with no issues.
The "length-hiding" code from the breach-mitigation-rails gem is not included here, as it is more complex, more brittle, and provides less protection against the attack - I don't think it's worth including.
Aug 20, 2014
1 check was pending
Q: why is strict base64 used instead of base64url with lenient decoding? This is causing us problems interoperating between systems because we use base64url for CSRF tokens. We moved to base64url to avoid having to separately url-encode the CSRF value in certain contexts. base64url is just a lot easier to plumb since it's intrinsically safe.
I don't believe there was any good reason for that choice, though it's been a while since I looked at this code. Any encoding function that is invertible and bijective should be fine here; we just need to get the bytes in to and out of portable strings.
However, changing the encoding function could cause backwards-incompatibility blips when users upgrade; any outstanding CSRF values might be rejected and have to be reissued. A minor issue I think.