Vij*_*ngh 3 security cookies csrf http-headers
我已经通过以下方式在我的 nodejs 服务器上实现了 CSRF 攻击预防 -
登录时的用户收到一个 CSRF 令牌和一个 cookie（基于 JWT 的令牌存储在 cookie 中）。CSRF 令牌成为使用$.ajaxSetup.
每当用户发出请求（GET 或 POST）时，我都会将客户端发送的 cookie 和 csrf 令牌（在标头中）与我服务器上存储的令牌进行比较，并且应用程序运行良好。
但是，当登录用户打开新选项卡或新浏览器窗口时，客户端拥有 cookie，但在其请求标头中没有 CSRF 令牌。所以服务器认为这是CSRF攻击并阻止请求！
我的问题是 - 在不影响 CSRF 安全性的情况下，如何在多个浏览器选项卡和窗口上运行相同的会话，而无需用户多次登录？
不要对 GET 请求使用 CSRF 保护。要在 GET 请求中传递 CSRF 令牌，您必须将其放入 URL 本身（例如，在查询参数中），并且 URL 不是放置安全敏感信息的好地方。它们倾向于通过各种方式泄漏，尤其是Referer在跟踪链接或从受保护页面获取资源时发送的标头。
您应该确保所有具有主动效果的操作（即更改数据库中的某些内容、写入文件系统或发送邮件的操作）仅通过 POST 请求公开，并使用 CSRF 令牌进行适当保护。没有任何活动效果的视图（例如查看页面、搜索内容）应该可以通过 GET 访问并且不需要 CSRF 保护。然后用户可以打开一个新选项卡并浏览到带有表单的页面而不会出错；将使用正确的参数生成表单，因此将提交 OK。
附带问题：您正在使用CSRF 保护的双重提交 Cookie方法。这是......好吧......但不能保护其他方法可以做到的一些场景。
（具体来说，如果攻击者可以执行 cookie 固定攻击——例如通过利用邻居/子域上的易受攻击的应用程序，或者通过 HTTP 对 HTTPS 站点的中间人攻击——他们可以通过让用户发送相同的内容来绕过 CSRF 保护他们在上一步中推送给用户的请求参数中的值。）
如果该站点是敏感站点或由于附近其他不太受信任的应用程序而特别容易受到此攻击，您可能希望考虑使用同步器令牌替代方案或加密令牌（也可以通过签名来完成；如果您没有使用任何类型的会话存储）。