Add support to avoid timing attacks in the csrf tokens

[eddumelendez]

Fixes gh-4001

[rwinch]

Thanks for the PR @eddumelendez!

This does not really solve the problem. We need to avoid the content of the page containing the same value on each request. As far as I can tell this does not solve the problem. The changes to CsrfToken and CsrfFilter look good, but I think we need to make some changes.

We need to update the DefaultCsrfToken getToken method to always return a different value. The value returned would be random bytes + xor(random bytes, original token value). The DefaultCsrfToken matches method would extract the random bytes (because it is a fixed length) and then xor it with the remaining bytes which calculates the original token value for comparison.

[eddumelendez]

Thanks for the feedback @rwinch. I will be adding more commits in this PRs following your notes :)

[rwinch]

Thanks for the PR @eddumelendez

gh-4001 is actually a different attack. It need what is written to the HTTP response to be random, but the CSRF token to be consistent. To do this we'd have the following:

• actual_csrf_token (this is the value that we have now and is consistent throughout the session)
• random_bytes - this is a secure random bytes Every time getToken is called we recalculate this value
• xor_csrf_token is xor(random_bytes,actual_csrf_token)
• result_csrf - This is random_bytes + xor_csrf_token

Then matches would see take the result_csrf:

• extract random_bytes from result_csrf by length
• extract xor_csrf_token from result_csrf by taking the remaining bytes
• calculate actual_csrf_token by xor(random_bytes,xor_csrf_token)

Cheers,
Rob

[rwinch]

Closing this since it is out dated and the feedback hasn't been applied