新选项卡和浏览器窗口中的CSRF令牌

Question

我已通过以下方式在我的nodejs服务器上实施了CSRF攻击预防—

登录时的用户收到CSRF令牌和cookie（基于JWT的令牌存储在cookie中）。CSRF令牌是使用$从客户端发送的所有未来请求头的一部分。ajaxSetup

每当用户发出请求（GET或POST）时，我都会将客户端发送的cookie和csrf令牌（在标题中）与服务器上存储的cookie和csrf令牌进行比较，应用程序工作正常

但是，当登录用户打开新选项卡或新浏览器窗口时，客户端具有cookie，但其请求头中没有CSRF令牌。因此，服务器将此视为CSRF攻击并阻止请求

我的问题是——在不损害CSRF安全性的情况下，如何在多个浏览器选项卡和窗口上运行相同的会话，而不需要用户多次登录？

Answer 1

我决定使用x-request-with标题。默认情况下，此标头是jquery中所有AJAX请求的一部分更多详细信息-
X-request-With头的意义是什么
https://security.stackexchange.com/questions/107906/alternative-to-anti-csrf-tokens-for-ajax-request-same-origin-policy这允许跨选项卡、跨窗口浏览，其中cookie用于用户身份验证，并检查x-request-with头以防止CSRF攻击。

Answer 2

不要对GET请求使用CSRF保护。要在GET请求中传递CSRF令牌，您必须将其放在URL本身中（例如在查询参数中），URL不是放置安全敏感信息的好地方。它们倾向于通过各种方式泄漏，尤其是在跟踪链接或从受保护的页面获取资源时发送的Referer标头。

您应该确保所有具有活动效果的操作（即，更改数据库中某些内容、写入文件系统或发送邮件的操作）仅通过POST请求公开，并使用CSRF令牌进行适当保护。没有任何积极影响的视图（如查看页面、搜索内容）应该可以通过GET访问，不需要CSRF保护。然后，用户可以打开一个新选项卡，浏览到带有表单的页面，而不会出现错误；表单将使用正确的参数生成，因此将提交OK。

附带问题：您正在使用CSRF保护的双重提交Cookie方法。这是。。。可以但不能像其他方法那样保护某些场景。

（具体来说，如果攻击者可以执行cookie固定攻击——例如通过利用邻居/子域上易受攻击的应用程序，或者通过HTTP对HTTPS站点的MitM攻击——他们可以通过让用户在请求参数中发送相同的值来绕过CSRF保护他们在上一步推送到用户。）

如果站点是敏感的，或者由于附近其他不太可信的应用程序而特别容易受到攻击，那么您可能希望考虑使用同步令牌替代方案，或者加密令牌（也可以仅用签名来完成；如果您不使用任何类型的会话存储，这是一个很好的选择）。