对我来说这似乎很冒险。HTTP 压缩适用于静态资源，但对于某些通过 SSL 提供的动态资源，HTTP 压缩似乎很危险。在我看来，HTTP 压缩在某些情况下可以允许类似 CRIME 的攻击。
考虑一个具有以下特征的动态页面的 Web 应用程序：
它通过 HTTPS 提供服务。
服务器支持 HTTP 压缩（如果浏览器支持 HTTP 压缩，此页面将以压缩形式发送到浏览器）。
该页面的某处有一个 CSRF 令牌。CSRF 令牌在会话的生命周期内是固定的（比如说）。这是攻击将尝试学习的秘密。
该页面包含一些可以由用户指定的动态内容。为简单起见，让我们假设有一些 URL 参数直接回显到页面中（可能应用了一些 HTML 转义来防止 XSS，但这很好，不会阻止所描述的攻击）。
然后我认为 CRIME 风格的攻击可能允许攻击者学习 CSRF 令牌并在网站上安装 CSRF 攻击。
让我举个例子。假设目标 Web 应用程序是一个银行网站www.bank.com，而易受攻击的页面是https://www.bank.com/buggypage.html。假设银行确保银行资料只能通过 SSL (https) 访问。并且，假设如果浏览器访问https://www.bank.com/buggypage.html?name=D.W.，那么服务器将响应一个看起来像这样模糊的 HTML 文档：
<html>...<body>
Hi, D.W.! Pleasure to see you again. Some actions you can take:
<a href="/closeacct&csrftoken=29238091">close my account</a>,
<a href="/viewbalance&csrftoken=...">view my balance</a>, ...
</body></html>
假设您正在通过开放的 Wifi 连接浏览网页，这样攻击者就可以窃听您的所有网络流量。假设您当前已登录您的银行，因此您的浏览器与您的银行网站有一个开放的会话，但您实际上并没有通过开放的 Wifi 连接进行任何银行业务。此外，假设攻击者可以引诱您访问攻击者的网站http://www.evil.com/（例如，可能通过对您进行中间人攻击并在您尝试访问其他 http 站点时重定向您）。
然后，当您的浏览器访问该页面时http://www.evil.com/，该页面会触发对您银行网站的跨域请求，以尝试获取秘密 CSRF 令牌。请注意，允许 Javascript 进行跨域请求。同源策略确实会阻止它看到对跨域请求的响应。尽管如此，由于攻击者可以窃听网络流量，因此攻击者可以观察所有加密数据包的长度，从而推断出通过 SSL 连接到您的银行下载的资源的长度。
特别是，恶意http://www.evil.com/页面可以触发请求https://www.bank.com/buggypage.html?name=closeacct&csrftoken=1并查看生成的 HTML 页面的压缩情况（通过窃听数据包并查看来自银行的 SSL 数据包的长度）。接下来，它可以触发一个请求https://www.bank.com/buggypage.html?name=closeacct&csrftoken=2并查看响应的压缩程度。依此类推，对于 CSRF 令牌的第一个数字的每种可能性。其中一个应该比其他压缩得好一点：URL 参数中的数字与页面中的 CSRF 令牌匹配的那个。这允许攻击者学习 CSRF 令牌的第一个数字。
通过这种方式，攻击者似乎可以学习 CSRF 令牌的每个数字，逐位恢复它们，直到攻击者学习整个 CSRF 令牌。然后，一旦攻击者知道了 CSRF 令牌，他就可以让他的恶意页面www.evil.com触发包含适当 CSRF 令牌的跨域请求——成功击败银行的 CSRF 保护。
如果启用了 HTTP 压缩，当上述条件适用时，这似乎允许攻击者对 Web 应用程序进行成功的 CSRF 攻击。攻击是可能的，因为我们将秘密与攻击者控制的数据混合到同一个有效载荷中，然后对该有效载荷进行压缩和加密。
如果还有其他秘密存储在动态 HTML 中，我可以想象类似的攻击可能会学习这些秘密。这只是我正在考虑的那种攻击的一个例子。因此，在我看来，在通过 HTTPS 访问的动态页面上使用 HTTP 压缩有点冒险。对通过 HTTPS 提供的所有资源禁用 HTTP 压缩可能有充分的理由，静态页面/资源（例如 CSS、Javascript）除外。