7

I know that enabling http compression would make a server vulnerable to the BREACH attacks. So we have disabled compression from the server side, tested and it was all good.

Then we implemented CloudFlare for the instance. We performed the SSL security scan again and found that the application is using gzip and so it is vulnerable to BREACH. From a detailed inspection we identified that the compression is enabled by CloudFlare.

Even though they claim that they have inbuilt BREACH attack prevention mechanism,folks from Security SE claims that BREACH can be exploited.

Then, in the next step, we disabled the Brotli compression offered by CloudFlare. But during testing, the scanner again detected compression. Now we are stuck. I understand that browser to CloudFlare traffic is compressed with Brotli and CloudFlare --> Server will remain uncompressed (since we have disabled gzip from the server side). Does this actually mitigate the BREACH attack issue?

If not, what recommendation do you people suggest?

Anonymous Platypus
  • 1,392
  • 3
  • 18
  • 33

2 Answers2

3

Vulnerability scanners can be wrong. They often detect only the circumstances around a vulnerability, like compression, without actually testing to see if that circumstance is vulnerable. It's up to you to verify the validity of each detection presented by your scanner. To do this, you would have to launch a BREACH attack against CloudFlare. Please do not do this without clearing it with their security team first. You would be seen as a real threat if you performed penetration testing without permission. This is illegal in most jurisdictions.

This question can only be answered by their support team. In this case, you already have their answer. They have implemented a mitigation and they have verified it internally.

Cloudflare has patched all servers against these vulnerabilities. Also, the Cloudflare WAF has rules to mitigate several of these vulnerabilities including Heartbleed and ShellShock.

Close this item in your scanner as a False Positive.

HackSlash
  • 268
  • 1
  • 10
  • 1
    A discussion of cloudflare's mitigation research can be found here: https://blog.cloudflare.com/a-solution-to-compression-oracles-on-the-web/, and sounds exactly like sort of mitigation which would still cause false positives in a scanner, though it is unclear whether cloudflare are actually using this or some other mix of mitigations. – Jack Nov 08 '19 at 03:16
  • Thank you for the answer and comments. Seems like this solves my doubts. I will post the answer here once I get a clear idea from the Cloudflare team. – Anonymous Platypus Nov 10 '19 at 07:42
1

Quoting the response from cloudflare community support:

I have no idea why a 3rd party reporting tool would indicate it is, but in my experience it is much more likely that the tool is poorly designed (checking for the ability to request gzip content for example rather than actually trying to exploit the vulnerability). However, if they believe they have an actual exploit, Cloudflare participates in the HackerOne program for responsible disclosure and they can report it there.

The second question is “Why is my content compressed through Cloudflare?” The answer to that is Cloudflare will by defualt support compression when a client requests it. We support gzip by default and optionally Brotli. You have disabled Brotli compression, but our default behavior remains in place unless it is overridden by explicit cache control directives. You can include a no-transform directive in your cache headers to prevent Cloudflare from applying compression.

So, I am concluding that the scanner's response was a false positive and marking the issue as solved.

Reference:

Anonymous Platypus
  • 1,392
  • 3
  • 18
  • 33