Employ techniques to mitigate BREACH. about nosurf HOT 7 CLOSED

There's a good discussion here: https://code.djangoproject.com/ticket/20869

It seems that either a simple XOR or AES are equally sufficient: XOR is probably faster, although that's a guess. I'm not sure how low-level Go's AES implementation is.

I might see if I can hack together a quick patch for this (it'll be useful for my own CSRF middleware) when I have some time this weekend. Feel free to beat me to it, though!

from nosurf.

Note: I've run some quick and dirty tests for masking CSRF tokens per-request using a few of the "popular" methods addressed by the Rails gem (XOR), the django-debreach (AES) and in the Django discussion linked above.

BenchmarkXOREncode        500000              3231 ns/op
BenchmarkXORDecode        500000              3017 ns/op
BenchmarkHMACHash         500000              6387 ns/op
BenchmarkHMACCompare      500000              6028 ns/op
BenchmarkAESCBCEncrypt    500000              4465 ns/op
BenchmarkAESCBCDecrypt    500000              4532 ns/op

You can find the source here: https://gist.github.com/elithrar/172705ee03c4fed068af

My opinion would be that the difference, on a per-request basis, is ultimately pretty small: 0.003017ms to decode an XORed token vs. 0.006028ms to decode a HMACed token. The downside to the AES route is the output size is going to be longer—and there's a fair bit more code complexity (you need to pad, unpad & generate an IV) for ultimately no gain over just vanilla XORing. XORing also allows you to keep your current middleware mostly "as is", too.

from nosurf.

Thanks for running the tests! Sorry for not having told you before, but
I've actually begun implementing the encryption using one time pad, just
haven't pushed the branch yet. Still have to fit it in the current API
nicely.

OTP seems like the way to go from your benchmarks as well.

from nosurf.

@justinas No problems: I'm implementing this (more cleanly than my Gist, mind you!) for my own [tiny] CSRF middleware, but figured you would benefit from the benchmarks as well. I was mostly curious to determine why XOR seemed the favorite.

from nosurf.

Well as the token is a short string, there's no need for a block cipher
like AES, I think, as the key for OTP will be short as well. And, like you
said, OTP is simpler.

I've also been thinking of writing benchmarks for common operations (get,
get then post, etc., with and without nosurf) and then comparing the breach
branch with the master now. This should help measure the real impact of
encryption in the request handling lifecycle.

from nosurf.

An (apparently) working implementation of encrypted tokens is now on the breach branch. Tests do pass, but another pair of eyes wouldn't hurt.

Benchmarks would also be useful, though I haven't finished them yet, as the test HTTP server has a relatively high overhead and thus makes the results useless and extracting the cookies directly from ResponseWriter is PITA. I'll most likely finish writing them using the latter way.

from nosurf.

Eh, what the hell, masked tokens are up on develop and master (6f31678).

from nosurf.