Improve request token to mitigate BREACH attacks

[rcubetrac]

Reported by Chumba on 7 Aug 2013 07:01 UTC as Trac ticket #1489277

Roundcube sites running on SSL/TLS may be subject to BREACH attacks. To mitigate the attack, one could improve the csrf token generated by Roundcube. Currently it consists of a random string of 32 characters (md5('RT' . $this->get_user_id() . $this->config->get('des_key') . $sess_id)))). Instead, it is suggested to do the following:

The researchers who discovered the attack suggest mitigating it by "masking" secret tokens so they are different on each request. This implements their suggested masking approach from section 3.4 of the paper (PDF). The authenticity token is delivered as a 64-byte string, instead of a 32-byte string. The first 32 bytes are a one-time pad, and the second 32 are an XOR between the pad and the "real" CSRF token. The point is not to hide the token from the client, but to make sure it is different on every request so it's impossible for an attacker to recover by measuring compressability.

Keywords: ssl breach token csrf
Migrated-From: http://trac.roundcube.net/ticket/1489277

[rcubetrac]

Comment by @alecpl on 8 Sep 2015 09:23 UTC

Attached proposed fix.

[rcubetrac]

Milestone changed by @alecpl on 8 Sep 2015 09:23 UTC

later => 1.2-beta

[rcubetrac]

Comment by @alecpl on 9 Sep 2015 08:43 UTC

While the patch improves the situation, I think it does not fully prevent from such attacks in ajax applications. I mean that in our case still the same token can be sent many times (from browser to server). We would need probably also do XOR-encrypting the token on client-side every time the ajax request is made.

[rcubetrac]

Milestone changed by @alecpl on 9 Sep 2015 08:43 UTC

1.2-beta => later