为什么我要在JWT令牌中放置一个CSRF令牌？

Question

我想从风暴路径柱中对JWT令牌和CSRF产生疑问，这说明了在localStorage或cookies中存储JWT的优点和缺点。

..。如果您正在使用JS从cookie中读取值，这意味着您不能在cookie上设置Httponly标志，所以现在站点上的任何JS都可以读取它，从而使其与在localStorage中存储某些东西的安全性级别完全相同。 我试图理解为什么他们建议将xsrfToken添加到JWT中。在cookie中存储JWT，然后提取JWT，然后将JWT放在HTTP报头中，并基于HTTP报头对请求进行身份验证，这样会完成与角的XSRF令牌相同的任务吗？如果您基于标头中的JWT进行身份验证，则没有其他域可以代表用户提出请求，因为其他域无法从cookie中提取JWT。我不明白xsrfToken在JWT中的用途--也许它只是一个额外的防御层--这意味着攻击者必须在您的站点上有一个妥协的脚本，而CSRF是当时的用户。所以他们必须用两种方式打你才能阻止攻击。

这篇文章是在这个答案链接的，上面写着：

最后一件事是确保在每个HTTP请求上都有CSRF保护，以确保向站点发起请求的外部域不能正常工作。 ..。然后，在进入服务器的每个请求中，确保自己的JavaScript代码读取cookie值，并在自定义标头(例如)中设置cookie值，并在服务器中的每个请求上验证该值。外部域客户端不能为您的域设置请求的自定义头，除非外部客户端通过HTTP请求获得授权，因此任何对CSRF攻击的尝试(例如在IFrame中)都将失败。

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

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

因此，方程式应该是：

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

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

更新： MvdD同意我的观点

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

Answer 1

我是“风暴路径”博客文章的作者。在JWT中存储XSRF令牌不是关于它在JWT中，而是在于它在cookie中。cookie应该是httpOnly，所以您不能从Javascript中读取它。

现在，我想引起一些混乱的一点是我谈论角度的问题。角度设置--也只有XSRF (不是httpOnly) --在请求时将其放入标头(这只能由javascript在同一域中完成)。这不是同一块饼干。

如果考虑在应用程序中实现XSRF支持，这是通过存储服务器端状态和存储XSRF的目的来完成的。将其存储在httpOnly cookie中是关于使用XSRF实现无状态的。在这里，您将验证JWT签名，从声明中获取XSRF，并将其与标头进行比较。

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

Answer 2

我的理解是：

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

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