OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

odata message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: CSRF Tokens in HTTPS streams

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:

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


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,

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]