为什么应该将 CSRF 令牌放入 JWT 令牌中？

我想对 JWT 代币和 CSRF 提出疑问风暴之路帖子 https://stormpath.com/blog/where-to-store-your-jwts-cookies-vs-html5-web-storage/解释了将 JWT 存储在 localStorage 或 cookie 中的优点和缺点。

[...] 如果您使用 JS 从 cookie 中读取值，这意味着您 无法在 cookie 上设置 Httponly 标志，因此现在您网站上的任何 JS 可以读取它，从而使其具有与存储完全相同的安全级别 本地存储中的东西。

我试图理解为什么他们建议将 xsrfToken 添加到 智威汤逊。不会将您的 JWT 存储在 cookie 中然后提取它 并将 JWT 放入 HTTP 标头中并验证 基于 HTTP 标头的请求完成与以下相同的事情 Angular 的 X-XSRF-TOKEN？没有其他域可以向 如果您基于标头中的 JWT 进行身份验证，则代表用户， 因为其他域无法从 cookie 中提取 JWT。我不 了解 JWT 中 xsrfToken 的用途 - 也许它只是 额外的防御层 - 这意味着攻击者必须 您的网站上有一个受损的脚本，并且当时有一个用户存在 CSRF。所以 他们必须以两种方式攻击你才能发动攻击。

该帖子链接在这个答案 https://stackoverflow.com/a/28953341/3517383其中说：

最后一件事是确保您的每个设备都具有 CSRF 保护 HTTP请求保证外部域发起请求 您的网站无法运行。

[...] 然后，在每个请求进入您的服务器时，请确保您自己的 JavaScript 代码读取 cookie 值并在自定义中设置它 标头，例如X-CSRF-Token 并在每个请求中验证该值 服务器。外部域客户端无法设置自定义标头 除非外部客户端获得授权，否则向您的域发出请求 通过 HTTP 选项请求，因此任何 CSRF 攻击的尝试（例如在 IFrame，无论如何）都会失败。

即使他们可以设置自定义标头，他们也无法访问存储 JWT 令牌的 cookie，因为只有在同一域上运行的 JavaScript 才能读取该 cookie。

他们唯一的方法是通过 XSS，但如果存在 XSS 漏洞，JWT 中的 xsrfToken 也会受到损害，因为在受信任的客户端域中运行的恶意脚本可以访问 cookie 中的 JWT，并在请求中包含带有 xsrfToken 的标头。

所以等式应该是：

• TLS + JWT 存储在安全 cookie 中 + JWT 位于请求标头中 + 无 XSS 漏洞。

如果客户端和服务器在不同的域中运行，服务器应发送 JWT，客户端应使用 JWT 创建 cookie。 我认为这个等式对于这种情况仍然有效。

UPDATE: MvdD 同意我的观点 https://stackoverflow.com/a/27084126/3517383:

由于浏览器不会自动将标头添加到您的请求中， 它不容易受到 CSRF 攻击

我的理解是这样的：

• 存储 JWT 是一个 HTTPonly cookie。
• 在该 JWT 中，存储 XSRF 令牌的哈希版本。
• 当客户端登录时向他们发送 XSRF 令牌，以便他们可以将其存储在本地存储中
• 稍后，当客户端发送请求时，JWT 会通过 cookie 自动随每个请求一起发送，然后您还可以通过标头或查询变量发送 XSRF 令牌，并在服务器端重新哈希以与服务器上 JWT 中的内容进行比较

您的 JWT 会受到保护，不会在 XSS 中被盗，并且您也会受到 XSRF 的影响。 XSS 仍然可以在您的浏览器上执行，但只能对浏览器中的该会话造成损害。最终，您无法阻止某人编写在您的浏览器上运行的非常详细的脚本，因此 Web 开发人员仍然需要防止 XSS 的传统安全措施。