5

One of our automated pen test tools picked up a potential BREACH attack in one of our applications. (BREACH is similar to CRIME and takes advantage of HTTP compression.)

The exploit was in a piece of JavaScript that issues a request to a .NET controller with a query string parameter that is then reflected in the page.

My fix for this was to ensure the content length of the request always varies by appending a new query string parameter 'token' with a random string of random length (1 - 10 chars). The idea behind this is that if the attacker cannot be sure if the request sizes are constant, they cannot exploit the flaw. This came back clear from the scan but I was wondering - is this the best fix?

[updated] An attacker theoretically capture this (eg Fiddler) and modify this and bypass my security mechanism. The server does not know what value is expected, any value of any length could be passed in, the JS just randomises a string.

  • 4
  • My employed method is listed on the linked post as an acceptable approach as 'Randomizing secrets per request'. Linked post provides a good list of approaches for mitigation. I've clarified the question a little. – iainpb Dec 14 '16 at 13:21
  • "...An attacker theoretically capture this.." - if the attacker is a man in the middle and is already able to modify the data he has no need to do BREACH because he can just read the secret from the decrypted data. – Steffen Ullrich Dec 14 '16 at 15:27
  • Can you disable compression? Or only enable compression for static content? – CodesInChaos Dec 14 '16 at 15:29
  • Disabling compression is definitely one way to fix the issue, from an article I read it's HP's suggested approach. It's not a welcomed approach by our infrastructure team and our applications have virtually no static content. I feel my fix has cleared the issue from the scan but hasn't actually fixed the issue, so this might be something I need to revisit with them. – iainpb Dec 14 '16 at 16:03

Browse other questions tagged or ask your own question.