我已经通过以下方式在我的nodejs服务器上实现了CSRF攻击防范 -
登录用户收到CSRF令牌和cookie（存储在cookie中的基于JWT的令牌） . CSRF令牌是使用 $.ajaxSetup 从客户端发送的所有未来请求标头的一部分 .
每当用户发出请求（GET或POST）时，我将客户端发送的cookie和csrf令牌（在 Headers 中）与我服务器上存储的令牌进行比较，并且应用程序正常工作 .
但是，当登录用户打开新选项卡或新浏览器窗口时，客户端具有cookie但在其请求标头中没有CSRF令牌 . 因此服务器将此视为CSRF攻击并阻止请求！
我的问题是 - 在不牺牲CSRF安全性的情况下，如何在多个浏览器选项卡和窗口上运行相同的会话而无需用户多次登录？
2 回答
不要对GET请求使用CSRF保护 . 要在GET请求中传递CSRF令牌，您必须将其放入URL本身（例如，在查询参数中），并且URL不是放置安全敏感信息的好地方 . 它们倾向于通过各种方式泄漏，尤其是在跟踪链接或从受保护页面获取资源时发送的
Referer标头 .您应确保所有具有活动效果的操作（即，更改数据库中的内容，写入文件系统或发送邮件的操作）仅通过POST请求公开，并使用CSRF令牌进行适当保护 . 没有任何有效效果的视图（例如查看页面，搜索某些内容）应该可以通过GET访问，并且不需要CSRF保护 . 然后，用户可以打开一个新选项卡并浏览到包含表单的页面而不会出现错误;表单将使用正确的参数生成，因此将提交确定 .
附带问题：您正在使用CSRF保护的Double Submit Cookie方法 . 这是......好吧......但不保护其他方法的一些场景 .
（具体来说，如果攻击者可以执行cookie固定攻击 - 例如通过利用邻居/子子域上的易受攻击的应用程序，或通过HTTP上的MitM攻击到HTTPS站点 - 他们可以通过让用户发送相同的内容来绕过CSRF保护它们在上一步中推送到用户的请求参数中的值 . ）
如果该站点是敏感站点或由于附近其他不太受信任的应用程序而特别容易受到攻击，您可能希望考虑使用Synchronizer Token备选方案，或者Encrypted Token（也可以通过签名来完成;如果您不是使用任何类型的会话存储） .
我决定使用
x-requested-withHeaders . 默认情况下，此标头是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攻击 .