为什么我要将CSRF令牌放入JWT令牌中？

Question

我想从Stormpath帖子中对JWT令牌和CSRF提出疑问，这些令牌和CSRF解释了将JWT存储在localStorage或Cookie中的优缺点。

[...] 如果您使用JS从cookie中读取值，这意味着您不能在cookie上设置Httponly标志，因此现在站点上的任何JS都可以读取它，从而使其与在localStorage中存储内容的安全级别完全相同。

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

这篇文章的链接如下：

最后一件事是确保您在每个HTTP请求上都有CSRF保护，以确保向您的站点发起请求的外部域无法正常工作。

[...]然后，在您服务器的每一个请求中，确保您自己的JavaScripthtml" target="_blank">代码读取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。我认为这个等式仍然适用于这种情况。

更新：MvdD同意我：

由于浏览器不会自动将标头添加到请求中，因此不会受到CSRF攻击

Answer 1

我的理解是：

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

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

Answer 2

我是暴风博客的作者。在JWT中存储XSRF令牌不是因为它在JWT中，而是因为它在cookie中。cookie应该是http的，所以你不能从Javascript中读取它。

现在，我想引起一点混乱的是，我谈论的角度。Angular设置只有XSRF cookie（不是httpOnly）在请求时将其放入头中（只能由同一域上的javascript完成）。这些不是同一块饼干。

如果您考虑在应用程序中实现XSRF支持，那么存储服务器端状态和XSRF的存储点已经完成了。将其存储在httpOnly cookie中意味着使用XSRF是无状态的。在这里，您将验证JWT签名，从声明中获取XSRF，并将其与标头进行比较。

您的问题的答案是，您不需要在服务器上存储状态。