关于JWT和CSRF合作，我仍然不清楚 . 我理解JWT的基本原理（它是什么以及它是如何工作的） . 当与会话一起使用时，我也理解CSRF . 同样地，我知道将JWT存储在localStorage中存在风险，这就是您需要csrf令牌的原因 . 所以我的问题是，我如何使用它们 . 为简单起见，我说我有一个登录页面 .
1）我有用户登录，一旦消费了电子邮件和密码，如果用户通过身份验证，服务器将发送CSRF，并将使用JWT存储httpOnly cookie（如何使用PHP设置cookie） . 我的理解是你可以使用 header('Set-Cookie: X-Auth-Token=token_value; Secure; HttpOnly;'); 请确认是否这样做 .
2）一旦我用JWT设置了cookie . 我如何使用后续请求发送CSRF令牌>从我的理解，您将它们设置在 Headers 中 . 因此，如果我正在发出Ajax请求，我会将它们放在 Headers 中 .
3）一旦发出请求并且CSRF令牌与请求一起发送 . 如何进行验证 . 我比较什么？
最后，这是否安全实施！
如果您能尽可能多地包含详细信息，我将非常感谢 .
2 回答
我自己看过和使用过的一种方法是将CSRF令牌包含在JWT中作为声明 . 因此，当用户发送用户名和密码时，您可以执行以下操作：
如果用户名和密码正确，请继续以下列表 .
创建新的JWT并在有效负载中包含生成的CSRF令牌作为声明，然后签署JWT .
通过设置包含JWT的
HTTPOnlycookie来响应客户端的身份验证请求 . 这可确保只有浏览器（不是客户端应用程序和可能的恶意脚本）才能访问JWT . 将cookie设置为secure也是一个好主意 . 如果使用不安全的通信信道（即不是https），这可以防止浏览器发送cookie .设置JWT cookie时，还应设置HTTP标头，该标头还将包含生成的CSRF标记 . 请注意，现在您将CSRF令牌放入JWT cookie和HTTP标头内的位置 .
在客户端应用程序中，将 Headers 中的CSRF令牌存储到localstorage中 .
对于每个请求，从localstorage获取CSRF令牌并将其作为请求标头包含（包含JWT的cookie由浏览器自动传递） .
服务器应从cookie中读取JWT，验证其签名并从请求标头中的JWT 's payload. Then it should compare it against the CSRF token that'读取CSRF令牌 . 如果匹配，则服务器可以继续处理请求 .
我建议你看看this谈论JWT . 它详细介绍了相同的方法（也有很好的图表） . 您可以随意观看整个演讲，或者如果您对CSRF特别感兴趣，请从36:29开始 .
以下是幻灯片（来自上面链接的演示文稿），演示了JWT和CSRF令牌如何一起使用 . 我用红色数字注释它，对应于上面的清单 .
防范CSRF的常见范例，它为每个“表单”生成一个令牌，并验证为特定表单设置的令牌是否正确 .
这样，攻击者就无法猜出令牌，因此可以制作发送到您服务器的外部表单 .
通常，设置该令牌的方法是通过
Cookie并且客户端应用程序将它附加到某个自定义标头，这将为您提供额外的保护，然后，服务器应该比较cookie值和标头值 .它是 important ，该令牌仅对一个会话有效，否则，攻击者可以重用他在攻击向量中获得的相同令牌 .
JWT是一种向系统验证用户不验证请求是否有效的方法 .
我将尝试通过示例解释，假设您没有实施任何针对CSRF的保护，但您确实有一种机制来验证您的用户（使用JWT），因此用户使用正确的用户登录并通过，服务器将发送一个JTW，客户端将其保存到localStorage . 现在，攻击者可以在他的站点上制作一个指向你的服务器的表单，假设他知道用户JWT令牌（他用MITM等其他方法得到它），他需要做的就是欺骗用户进入他的带有表单的页面，如果有任何问题，表单将被发送给您，您的服务器将接受请求并且攻击将成功 .
如果您实施任何CSRF机制，示例中的攻击者将无法猜测当前令牌，因此您的服务器将忽略其请求 .