RE: [odata] CSRF Tokens in HTTPS streams

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

Hi Stefan,

I'd recommend this in the Committee Note on Securing OData. This is the only place where we (will soon :-) talk about CSRF protection, and it is just another recommendation on how to use it.

This new attack confirms my belief that it was a good decision to keep security considerations mostly out of the Core specs and instead collect them in a non-normative Note that we can update with a single majority vote and without the public review process.

Thanks!
--Ralf

-----Original Message-----
From: Stefan Drees [mailto:stefan@drees.name] 
Sent: Wednesday, 7. August 2013 08:53
To: Handl, Ralf
Cc: odata@lists.oasis-open.org
Subject: Re: [odata] CSRF Tokens in HTTPS streams

Hi Ralf,

I think your (below) proposal describes a good mitigation should OData 
transactions become subject of this attack.

Restricting the request types that allow fetching CSRF tokens per "soft 
non-normative" advice or (as I presume) in the normative core docs ... ?

All the best,
Stefan.
Am 07.08.13 07:59, schrieb Handl, Ralf:
> 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
>