security - 新标签页和浏览器窗口中的 CSRF token

Question

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

登录的用户会收到一个 CSRF token 和一个 cookie(存储在 cookie 中的基于 JWT 的 token )。 CSRF token 成为客户端使用 $.ajaxSetup 发送的所有 future 请求 header 的一部分。

每当用户发出请求(GET 或 POST)时，我都会将客户端发送的 cookie 和 csrf token (在 header 中)与存储在我的服务器上的内容进行比较，应用程序运行正常。

但是，当登录用户打开新选项卡或新浏览器窗口时，客户端有 cookie 但在其请求 header 中没有 CSRF token 。所以服务器认为这是一个 CSRF 攻击并阻止请求!

我的问题是 - 在不影响 CSRF 安全性的情况下，如何让同一个 session 在多个浏览器选项卡和窗口上运行而无需用户多次登录？

Answer 1

不要对 GET 请求使用 CSRF 保护。要在 GET 请求中传递 CSRF token ，您必须将其放在 URL 本身中(例如，在查询参数中)，而 URL 不是放置安全敏感信息的好地方。它们往往会通过多种方式泄露，尤其是在跟踪链接或从 protected 页面获取资源时发送的 Referer header 。

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

附带问题:您正在使用 Double Submit Cookie CSRF保护方法。这……好吧……但不能像其他方法那样保护某些场景。

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

如果该站点是敏感站点，或者由于附近其他不太受信任的应用程序而特别容易受到此影响，您可能希望考虑使用 Synchronizer Token替代方案，或 Encrypted Token (也可以通过签名来完成；如果您不使用任何类型的 session 存储，这是一个很好的选择)。