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: Re: [odata] CSRF Tokens in HTTPS streams

Hi Ralf,

I share this point. Just wanted to be sure ;-)

All the best,
Am 07.08.13 09:14, schrieb Handl, Ralf:
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.


-----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,
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.


-----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:

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,

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:

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