3 ms·

Your app is vulnerable if it includes content from the user (e.g. a GET query parameter or something from a POST request body) in the response, and includes sec

Your app is vulnerable if it includes content from the user (e.g. a GET query parameter or something from a POST request body) in the response, and includes secret info (e.g. an anti-CSRF token) in that same response.

nickysielicki 11y ago
Wow, that's scary. I imagine quite a lot of people are unaware of this. I personally use SSL on my personal site just because I like the idea that readers can be sure the content is what I've sent, rather than because the information is private / sensitive. So I'm not personally concerned because this doesn't allow anyone to MITM the connection, just read it.
nine_k 11y ago
I suppose that adding a small random bit into the page could defeat this known-plaintext attack?
- strommen 11y ago
  Not really. The theory behind the attack is that if the user-specified content is equal to the secret content, it will compress more effectively and have a smaller content length. The other content on the page doesn't really matter. Adding data of random length will make the attack more difficult, but won't defeat it entirely. This is called length hiding. See http://breachattack.com/ http://breachattack.com/ for a more thorough explanation by smarter people.
  - nine_k 11y ago
    The attack depends on a secret to match a user-provided string enough for the compression algorithm to notice this redundancy? A counter-measure then would be to scramble the user input in the page with a random key, and include this key into the page for de-scrambling using JavaScript. It will still efficiently compress the parts of the page which are not user-controlled.
    - nickysielicki 11y ago
      > de-scrambling using JavaScript No thank you.
    - strommen 11y ago
      Yes and Yes (assuming your random key isn't guessable). breachattack.com suggests masking the secret with a per-request random key, but masking the user input would work too.

nickysielicki 11y ago

Wow, that's scary. I imagine quite a lot of people are unaware of this. I personally use SSL on my personal site just because I like the idea that readers can be sure the content is what I've sent, rather than because the information is private / sensitive. So I'm not personally concerned because this doesn't allow anyone to MITM the connection, just read it.

nine_k 11y ago

I suppose that adding a small random bit into the page could defeat this known-plaintext attack?

strommen 11y ago
Not really. The theory behind the attack is that if the user-specified content is equal to the secret content, it will compress more effectively and have a smaller content length. The other content on the page doesn't really matter. Adding data of random length will make the attack more difficult, but won't defeat it entirely. This is called length hiding. See http://breachattack.com/ http://breachattack.com/ for a more thorough explanation by smarter people.
- nine_k 11y ago
  The attack depends on a secret to match a user-provided string enough for the compression algorithm to notice this redundancy? A counter-measure then would be to scramble the user input in the page with a random key, and include this key into the page for de-scrambling using JavaScript. It will still efficiently compress the parts of the page which are not user-controlled.
  - nickysielicki 11y ago
    > de-scrambling using JavaScript No thank you.
  - strommen 11y ago
    Yes and Yes (assuming your random key isn't guessable). breachattack.com suggests masking the secret with a per-request random key, but masking the user input would work too.