RE: [odata] CSRF Tokens in HTTPS streams

["Handl, Ralf" <ralf.handl@sap.com>]

It seems to me that we can avoid one of the preconditions of this attack:

        [In order to conduct the attack, the following conditions must be true]:
         [...]
         4. A request parameter that is reflected in the response body.
         [...]

If we restrict fetching the CSRF token to service document requests, the only parameter reflected in the response body is the content-language. Its limited size of 5 characters should severely limit the attack.

Requests for an individual entity with string-valued key and a 404 response body that repeats the invalid key value definitely fulfills this precondition, so we'll have to restrict the request types that allow fetching the CSRF token.

Thoughts?


-----Original Message-----
From: odata@lists.oasis-open.org [mailto:odata@lists.oasis-open.org] On Behalf Of Stefan Drees
Sent: Wednesday, 7. August 2013 07:22
To: odata@lists.oasis-open.org; Hartel, Barbara
Subject: [odata] 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:
"""
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.

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php