我有一个场景，我已经有 CSRF 令牌，但我必须删除。在电子商务中，产品页面由 Varnish 缓存，因此如果用户直接登陆这里，他将没有会话 ID 来验证令牌。在此页面中，我有一个“添加到购物车”按钮，其中包含 CSRF 令牌，但当然它是用错误的令牌缓存的。
我的问题是：还有另一种方法可以在不依赖令牌隐藏的输入的情况下进行 CSRF 保护？放置按钮的页面必须被缓存，所以这种情况下的令牌不好。
谢谢。
【问题讨论】：
标签： caching csrf varnish csrf-protection
要使 CSRF 令牌生效，您需要能够在 cookie 机制之外提交它。您可以让您的页面对您的站点执行 AJAX POST 以检索 CSRF 令牌。
例如https://www.example.com/GetCSRFToken
回复：
{ "token": "abcdefg" }
然后，您将能够使用您的表单提交此令牌。由于这是一个单独的请求，因此响应不会成为您缓存页面的一部分。此方法的唯一缺点是必须启用 JavaScript 才能检索令牌。不过，您可能可以处理这种情况，如果由于禁用 JavaScript 而在没有令牌的情况下发布表单，您可以在将实际商品添加到购物车之前添加确认步骤。确认页面将被设置为不被缓存，因此每个用户将始终获得其会话的令牌。
【讨论】：
/getCSRFToken 的唯一方法是通过同源策略，否则可以通过简单地执行两个帖子而不是一个帖子来发起 CSRF 攻击（第一个帖子是获取 CSRF 令牌，第二个请求将是攻击请求），除非我遗漏了有关如何保护 /GetCSRFToken 的信息？
/SetCSRFTokenCooke 的请求会起作用吗？这样做我更有信心。
在 OWASP CSRF 预防备忘单中描述了一种替代方法，标题为 "Double Submit Cookies"
它与表单一起提交会话 ID，其中 javascript 读取此 cookie 值并将其作为隐藏的输入元素注入表单。为此，您的会话 cookie 不得标记为 HTTPOnly，这是一种不好的做法。因此，当您尝试在 CSRF 上添加一些会话 cookie 安全性时，您会失去一些会话 cookie 安全性。
作为对这种方法的改进，您可以创建另一个存储 CSRF 令牌值的登录 cookie，并使用此 cookie 代替 sessionid cookie。现在您可以将 sessionid cookie 标记为HTTPOnly。 （不将 csrf cookie 标记为 httponly 也是一种不好的做法，但不像以前那样重要）
（出于性能原因，我假设通过 AJAX 调用在每个页面上检索 csrf 令牌不是一种选择）
【讨论】：
您可以为 CSRF 使用 cookie，cookie 在表单页面上设置并在下一个页面上检查。它可能需要一些调整，但它会绕过缓存。
不要忘记将 Varnish 配置为不删除该 cookie。
【讨论】：