OASIS Open Data Protocol (OData) TC

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.

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

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

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 >

Hi Ralf, I share this point. Just wanted to be sure ;-) All the best, Stefan. 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. 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