CookieCsrfTokenRepository 允许客户端创建自己的 Csrf 令牌

Question

CookieCsrfTokenRepository 设置一个 cookie，并且在后续请求中，它只是将来自客户端的 cookie 值与来自标头的 cookie 值进行比较。

它不记得它是否仍然是第一次设置的值。它只是比较它们。

但是角度文档（https://angular.io/guide/http#security-xsrf-protection）说“令牌对于每个用户来说必须是唯一的，并且必须可由服务器验证；这可以防止客户端制作自己的令牌。 将令牌设置为站点身份验证 cookie 的摘要，并添加盐以增强安全性。”

那么CookieCsrfTokenRepository不安全吗？

Answer 1

CookieCsrfTokenRepository

类似于 OWASP CSRF Prevention Cheatsheet 中描述的“双重提交 cookie”模式。 虽然类似，但严格来说它并不是双重提交模式，因为关联的

CsrfFilter

并不要求令牌“双重提交”。 在验证请求时，过滤器会愉快地接受通过 cookie 传输的 CSRF 令牌，而不是要求将令牌作为请求参数双重提交，然后将参数与 cookie 进行比较。 因此，我假设该技术依赖于 CSRF 令牌 cookie 设置

SameSite=Strict

属性来防止 CSRF。

回答你的问题，

CookieCsrfTokenRepository

容易受到“cookie固定”的影响，如果攻击者能够设置CSRF cookie值。 攻击者可能通过 (ref) 来实现此目的：

• 利用子域。
• HTTP 连接上的中间人攻击。

上述风险/可行性取决于您的应用程序配置。

基于 cookie 的 CSRF 缓解方法可以通过多种方式进行强化：

• HTTP 严格传输安全 (HSTS) - 防止中间人攻击。
• Cookie 前缀（“__Host-”是您想要的前缀）- 防止子域设置 CSRF 令牌 cookie。
• 对令牌进行签名（使用只有服务器知道的私钥或秘密）
• 将令牌绑定到用户或会话（例如使用当前会话 ID 的 HMAC）。
• 如果您的应用程序使用 AJAX 请求，请使用自定义 HTTP 标头。

OWASP CSRF 预防备忘单（上面链接）很好地总结了 CSRF 预防方法和权衡。