我一直在阅读有关 JWT 的信息，据我了解，它是用户登录后服务器发送的令牌。用户必须在所有未来的 HTTP 请求中发送该令牌。这为服务器创建了一种无状态的方式来验证用户的请求。
现在我不明白的是，如果 JWT 在标头中发送并仅标记为 HTTP，为什么还需要 CSRF 令牌来防止 CSRF 攻击？我的理解是 JWT 和 CSRF 令牌都与用户相关联，JWT 可以同时满足这两个目的。
我了解使用了 CSRF 令牌，因此不会接受来自其他网站的 HTTP 请求。 JWT 怎么不能做到这一点？是什么将 CSRF 令牌与 JWT 令牌分开，并允许它实现这一区别？
我一直在阅读有关 JWT 和 CSRF 令牌以及双重提交方法的文章，但我似乎无法理解或遗漏了一些内容。
【问题讨论】：
标签： jwt csrf http-token-authentication
基于存储在 cookie 中的令牌（JWT 或随机）的身份验证系统容易受到 CSRF 攻击，因为 cookie 会在每个请求中自动发送到服务器，攻击者可能会构建一个有害的 url 链接到您的网站。
https://yoursite.com/delete?something=1
为了保护您的网站，需要使用您的应用程序必须在以下请求中发送的 CSRF 令牌（而不是在 cookie 中）。
或者，您可以将 JWT 存储在 localStorage 中并将其发送到 Authorization 标头中，这样您的站点就会受到 CSRF 保护，但它可能容易受到 XSS 攻击。始终考虑您选择的技术解决方案的安全考虑
更新 ¿为什么将 JWT 存储在本地存储中可能容易受到 XSS 攻击？
查看将令牌存储在 localstorage 和 http-only cookie 之间的比较https://academind.com/tutorials/localstorage-vs-cookies-xss
攻击者可以注入 javascript 代码从本地存储中读取令牌并将其发送到他自己的服务器。但是，这种类型的攻击对于仅 http 的 cookie 是不可能的，因为它无法从 javascript 访问
【讨论】：
same-origin 策略。 2）在您的链接中设置了cookie，但是使用javascript读取并在标头中发送（它不是httponly），它不是由浏览器自动发送的，这是CSRF攻击的关键
您的所有问题都与 NEVER 中的 CSRF 令牌包含在 cookie 中以及 JWT 令牌可以在 cookie 中发送这一事实有关。
可以发送 JWT 令牌：
1- 在 cookie 中
2- 在另一种类型的标题中
3- 在标题之外，在某些 POST 属性中
4- 在标头之外，在一些 GET 参数中（不是很常见）
但对于无状态身份验证，您必须使用 cookie（情况 1）。
因此，对于无状态身份验证，您很容易使用您的 JWT 令牌进行 CSRF。这就是为什么您需要添加一些 CSRF 缓解机制，基于 cookie 中未包含的更多信息，或者 不仅 包含在 cookie 中。
如果您接受实施有状态身份验证，所有这些都将不适用。
【讨论】：