django - 在 Django >= 1.10 中使用 GZip 中间件是否安全？

Question

我希望在 Django 中启用文本压缩。 performance docs引用 GZip 中间件作为当前文本压缩的解决方案。但是，它带有一个严厉的警告:

GZipMiddleware

Compresses responses for all modern browsers, saving bandwidth and transfer time. Note that GZipMiddleware is currently considered a security risk, and is vulnerable to attacks that nullify the protection provided by TLS/SSL. See the warning in GZipMiddleware for more information.

几个问题:

是否有任何文本压缩替代方案可以与 Django 一起使用且不受安全风险的影响？

如果我在使用 POST 时使用 CSRF token 并且我启用了 CSRF 中间件我安全吗？

再次，通过 the docs :

Changed in Django 1.10: In older versions, Django’s CSRF protection mechanism was vulnerable to BREACH attacks when compression was used. This is no longer the case, but you should still take care not to compromise your own secrets this way.

Answer 1

我绝对建议查看 BREACH paper ，这很短而且很清楚。

正如那里所指出的:

In order for the attack to be successful, several things are required. To be vulnerable to this side-channel, a web app must:

1. Be served from a server that uses HTTP-level compression
2. Reflect user-input in HTTP response bodies
3. Reflect a secret (such as a CSRF token) in HTTP response bodies

因此，如果您没有在响应正文中反射(reflect)用户信息和 secret ，那么您就不会受到攻击。

如果是，那么任何文本压缩方案都不太可能奏效。这种攻击利用了文本压缩的基本特性:重复的文本应该占用更少的空间。有可能存在不易受到攻击的压缩方案，但您肯定需要看到一些保证。

由于此攻击基于特定的应用程序功能，而不是框架漏洞，因此 Django 无法确保应用程序是“安全的”。 Django 可以做的是保护它提供支持的易受 BREACH 攻击的主要 secret :CSRF token 。从 1.10 版开始，Django 使用了论文中建议的一种缓解措施(参见第 3.4 节)到 protect it from this attack :

In order to protect against BREACH attacks, the token is not simply the secret; a random salt is prepended to the secret and used to scramble it.

总而言之:如果您需要保护的唯一 secret 是 Django 的 CSRF token ，并且您使用的是 Django 1.10 或更高版本，则可以合理地得出结论，您可以使用 gzip 并且仍然可以避免 BREACH。