我已经通过以下方式在我的 nodejs 服务器上实现了 CSRF 攻击防护 -
登录时的用户会收到一个 CSRF 令牌和一个 cookie（基于 JWT 的令牌存储在一个 cookie 中）。 CSRF 令牌成为客户端使用$.ajaxSetup 发送的所有未来请求标头的一部分。
每当用户发出请求（GET 或 POST）时，我都会将客户端发送的 cookie 和 csrf 令牌（在标头中）与我服务器上存储的进行比较，应用程序运行正常。
但是，当登录用户打开新标签页或新浏览器窗口时，客户端有 cookie，但其请求标头中没有 CSRF 令牌。所以服务器将此视为 CSRF 攻击并阻止请求！
我的问题是 - 在不影响 CSRF 安全性的情况下，如何在不让用户多次登录的情况下在多个浏览器选项卡和窗口上运行相同的会话？
【问题讨论】：
标签： security cookies http-headers csrf
不要对 GET 请求使用 CSRF 保护。要在 GET 请求中传递 CSRF 令牌，您必须将其放入 URL 本身（例如，在查询参数中），并且 URL 不是放置安全敏感信息的好地方。它们往往通过多种方式泄漏，尤其是在跟踪链接或从受保护页面获取资源时发送的 Referer 标头。
您应该确保所有具有主动效果的操作（也就是说，更改数据库中的某些内容、写入文件系统或发送邮件的操作）仅通过 POST 请求公开，并通过适当的保护CSRF 代币。没有任何活动效果的视图（例如查看页面、搜索内容）应该可以通过 GET 访问，并且不需要 CSRF 保护。然后，用户可以打开一个新选项卡并浏览到包含表单的页面而不会出现错误；表单将使用正确的参数生成，因此可以提交。
附带问题：您正在使用Double Submit Cookie CSRF 保护方法。这……好吧……但不能像其他方法那样保护某些场景。
（具体来说，如果攻击者可以执行 cookie 固定攻击——例如，通过利用邻居/子子域上的易受攻击的应用程序，或通过 HTTP 对 HTTPS 站点的中间人攻击——他们可以通过使用户绕过 CSRF 保护在请求参数中发送他们在上一步中推送给用户的相同值。）
如果该网站是敏感网站，或者由于附近的其他不太受信任的应用程序而特别容易受到此影响，您可能希望考虑使用Synchronizer Token 替代方案或Encrypted Token（也可以通过签名来完成；如果您不使用任何类型的会话存储，这是一个不错的选择）。
【讨论】：
我决定使用x-requested-with 标头。默认情况下，此标头是 jquery 中所有 AJAX 请求的一部分。
更多详情 -
What's the point of the X-Requested-With header?
https://security.stackexchange.com/questions/107906/alternative-to-anti-csrf-tokens-for-ajax-request-same-origin-policy
这允许跨表、跨窗口浏览，其中使用 cookie 进行用户身份验证，并检查 x-requested-with 标头以防止 CSRF 攻击。
【讨论】：