如果您的站点容易受到 BREACH 攻击，攻击者可以一次猜出响应正文中的任何一个字符。攻击者执行多个请求，每次猜测一个，并且可以查看他是否猜对了。例如，攻击者可能会尝试以下猜测：

• csrftoken=a
• csrftoken=b
• csrftoken=c
• 等等。

过了一会儿，他找出了令牌的第一个字符，然后转到下一个字符。如您所见，猜测整个 CSRF 令牌需要数百个请求。

这种攻击只有在所有请求都返回相同的 CSRF 令牌时才有效。如果请求之间的令牌不同，则攻击者无法使用多个请求来猜测它。因此，为了防止 BREACH 攻击，每个页面上的 CSRF 令牌应该不同。

但是，不必为每个请求创建一个新令牌。简单地混淆 CSRF 令牌就足够了。您可以像Django和Rails一样，使用包含在表单中的一些盐来加密甚至异或 CSRF 令牌。这意味着每个页面上的令牌都是不同的，但您仍然只需在后端检查一个值。

回答您的问题：如果您不使用基于会话的 CSRF 令牌和HTTP 压缩，它仍然是安全的（请参阅下面的说明）

来自breachattack.com /我受到影响了吗？

如果您的 HTTP 响应正文满足以下所有条件，则您可能容易受到攻击：

• HTTP 压缩您的页面在启用 HTTP 压缩的情况下提供 (GZIP / DEFLATE)
• 用户数据：您的页面通过查询字符串或 POST 参数反映用户数据
• 秘密：您的应用程序页面提供 PII、CSRF 令牌、敏感数据

缓解措施/按有效性排序

1. 禁用 HTTP 压缩
2. 从用户输入中分离秘密
3. 每个请求随机化秘密
4. 屏蔽秘密（通过 XORing 与每个请求的随机秘密有效地随机化）
5. 使用 CSRF 保护易受攻击的页面
6. 长度隐藏（通过在响应中添加随机字节数）
7. 对请求进行速率限制

这取决于“基于会话”的含义。

BREACH 攻击需要一次猜测你的 CSRF 令牌一个字符，并且每次猜测都需要发出新的请求。因此，为了猜测您的 CSRF 令牌，攻击者必须能够生成许多请求，这些请求都在返回的数据中包含相同的令牌。

如果“基于会话”是指 CSRF 令牌是：

• 每次登录时更新；
• 仅在登录时发送到浏览器一次

那么攻击就不行了。即使攻击者可以重放登录，他们每次都会获得一个新的 CSRF 令牌，因此无法猜测。

然而，简单地说“基于会话”本身并不安全。您的 CSRF 令牌可能与会话相同，但仍会随每个请求一起发回。例如Set-Cookie: csrftoken=...，即使令牌没有更改，惰性实现也可能随每个请求返回。

所以总而言之：从概念上讲，令牌是否基于会话并不重要。重要的是攻击者是否可以执行总是返回相同 CSRF 令牌的重复请求。

如果 BREACH 允许信息泄露，我们是否必须以基于时间或按请求的方式屏蔽或生成 CSRF 令牌以使其更安全？

确保对任何动态响应都禁用了HTTP 压缩，你应该没问题。

对于静态内容，您应该能够安全地启用压缩，因为不满足第二个条件：页面不反映用户数据查询字符串或 POST 参数。