我通过以下方式在我的nodejs服务器上实现了CSRF攻击预防 -
登录时的用户会收到 CSRF 令牌和 cookie（存储在 cookie 中的基于 JWT 的令牌）。 CSRF 令牌将成为客户端发送的所有未来请求标头的一部分$.ajaxSetup.
每当用户发出请求（GET 或 POST）时，我都会将客户端发送的 cookie 和 csrf 令牌（在标头中）与服务器上存储的内容进行比较，并且应用程序工作正常。
但是，当登录用户打开新选项卡或新浏览器窗口时，客户端具有 cookie，但其请求标头中没有 CSRF 令牌。所以服务器认为这是CSRF攻击并阻止该请求！
我的问题是 - 在不影响 CSRF 安全性的情况下，如何在多个浏览器选项卡和窗口上运行相同的会话，而无需用户多次登录？
不要对 GET 请求使用 CSRF 保护。要在 GET 请求中传递 CSRF 令牌，您必须将其放在 URL 本身中（例如，在查询参数中），而 URL 并不是放置安全敏感信息的好地方。它们往往通过多种方式泄露，尤其是Referer当跟踪链接或从受保护页面获取资源时发送标头。
您应该确保所有具有主动效果的操作（也就是说，更改数据库中的某些内容、写入文件系统或发送邮件的操作）仅通过 POST 请求公开，并使用 CSRF 令牌进行适当保护。没有任何主动效果的视图（例如查看页面、搜索某些内容）应该可以通过 GET 访问，并且不需要 CSRF 保护。然后，用户可以打开一个新选项卡并浏览到包含表单的页面，而不会出现错误；表单将使用正确的参数生成，因此将提交“确定”。
附带问题：您正在使用双重提交 Cookie https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet#Double_Submit_CookiesCSRF保护方法。这是......好吧......但不能保护其他方法所做的某些场景。
（具体来说，如果攻击者可以执行 cookie 固定攻击，例如通过利用邻居/子子域上的易受攻击的应用程序，或者通过 HTTP 对 HTTPS 站点进行 MitM 攻击，他们可以通过让用户发送相同的内容来绕过 CSRF 保护他们在上一步中推送给用户的请求参数中的值。）
如果该网站是敏感网站，或者由于附近有其他不太受信任的应用程序而特别容易受到此影响，您可能希望考虑使用同步器令牌 https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet#General_Recommendation:_Synchronizer_Token_Pattern替代方案，或加密令牌 https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet#Encrypted_Token_Pattern（也可以通过签名来完成；如果您不使用任何类型的会话存储，这是一个不错的选择）。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
