我知道启用 http 压缩会使服务器容易受到 BREACH 攻击。所以我们从服务器端禁用了压缩，经过测试，一切都很好。
然后我们为实例实现了 CloudFlare。我们再次执行 SSL 安全扫描，发现应用程序正在使用 gzip，因此容易受到 BREACH 攻击。通过详细检查，我们发现压缩是由 CloudFlare 启用的。
尽管他们声称他们已经内置了 BREACH 攻击预防机制，但Security SE 的人声称 BREACH 可以被利用。
然后，在下一步中，我们禁用了 CloudFlare 提供的 Brotli 压缩。但在测试期间，扫描仪再次检测到压缩。现在我们被困住了。我知道浏览器到 CloudFlare 的流量是用 Brotli 和 CloudFlare 压缩的——> 服务器将保持未压缩（因为我们从服务器端禁用了 gzip）。这真的缓解了 BREACH 攻击问题吗？
如果没有，你们有什么建议？
漏洞扫描器可能是错误的。他们通常只检测漏洞周围的情况，例如压缩，而不实际测试该情况是否易受攻击。由您来验证扫描仪提供的每个检测的有效性。为此，您必须对 CloudFlare 发起 BREACH 攻击。请不要在没有先与他们的安全团队清除的情况下执行此操作。如果您未经许可执行渗透测试，您将被视为真正的威胁。这在大多数司法管辖区都是非法的。
这个问题只能由他们的支持团队来回答。在这种情况下，您已经有了他们的答案。他们已经实施了缓解措施，并在内部进行了验证。
Cloudflare 已针对这些漏洞修补了所有服务器。此外，Cloudflare WAF 还制定了缓解其中几个漏洞的规则，包括 Heartbleed 和 ShellShock。
在您的扫描仪中关闭此项目作为误报。
引用 cloudflare 社区支持的回应：
我不知道为什么 3rd 方报告工具会表明它是，但根据我的经验，该工具更有可能设计不良（例如检查请求 gzip 内容的能力，而不是实际尝试利用该漏洞） . 但是，如果他们认为自己有实际利用，Cloudflare 会参与 HackerOne 计划进行负责任的披露，他们可以在那里报告。
第二个问题是“为什么我的内容是通过 Cloudflare 压缩的？” 答案是 Cloudflare 在客户端请求时默认支持压缩。我们默认支持 gzip 和可选的 Brotli。您已禁用 Brotli 压缩，但我们的默认行为保持不变，除非它被显式缓存控制指令覆盖。您可以在缓存标头中包含no-transform 指令，以防止 Cloudflare 应用压缩。
因此，我的结论是扫描仪的响应是误报，并将问题标记为已解决。
参考：