CSRF Tokens in HTTPS streams

[Stefan Drees <stefan@drees.name>]

Dear all,

while the summer has arrived on the northern hemisphere, there also came 
along some freshly known risks which might impact users of OData.

We decided to describe CSRF employing scenarios inside the security 
document. Maybe the BREACH compression attack (cf. 
http://www.kb.cert.org/vuls/id/987798) which currently seems to be not 
really mitigateable has impact on the document.

As I understand it, a fixed 32 Byte (hex) CSRF token might be stolen in 
quite realistic scenarios in well under 30 seconds.

Citing further from the CERT reference above:
"""
Impact

A sophisticated attacker may be able to derive plaintext secrets from 
the ciphertext in an HTTPS stream.

Solution

We are currently unaware of a practical solution to this problem. 
However, the reporters offer several tactics for mitigating this 
vulnerability. Some of these mitigations may protect entire 
applications, while others may only protect individual web pages.

1. Disable HTTP compression.
2. Separate the secrets from the user input.
3. Randomize the secrets in each client request.
4. Mask secrets (effectively randomizing by XORing with a random secret 
per request).
5. Protect web pages from CSRF attacksw.
6. Obfuscate the length of web responses by adding random amounts of 
arbitrary bytes.
"""

@Barbara: Maybe we could have a short exchange of ideas upon this during 
tomorrows meeting?

All the best,
Stefan.