Security 用u额外的uCookie针对XSS保护JWT？

我的理解是：

基于Cookie的解决方案可以通过使Cookie httpOnly成为安全的，从而轻松抵御XSS。但是，基于cookie的解决方案容易受到CSRF的影响（如果没有附加令牌的保护）

JWT在这里有一个优势，因为默认情况下CSRF是不可能的。 但是，JWT可以作为XSS弱点的一部分被利用，因为该令牌必须可用于JavaScript。这被认为不是什么大事，因为XSS更容易理解，也更容易防范

但是：为什么不使用JWT并同时添加一个httpOnly cookie（包含令牌的签名）来实现这两个方面的最佳效果呢

在生成令牌时，服务器还将从令牌生成签名并将其发送回cookie。（令牌仍将一如既往地发送给客户端。）（签名当然必须与令牌中包含的签名不同。）

当服务器收到请求时，它会检查cookie是否也被发送，并将其值与新计算的令牌签名进行比较

所以：由于这种方法还没有普遍实现，所以我一定忽略了一些重要的东西，对吗

---

（我想到的唯一问题是cookie和多域/COR的老问题。）

通过在存储令牌的cookie上设置HttpOnly，令牌会在每次请求时发送到cookie内部的Web服务器，服务器必须自动读取和处理它。CSRF攻击的工作原理是使您的浏览器通过其身份验证cookie（在本例中是包含令牌的cookie）发送恶意请求。如果您的令牌在cookie中自动传递到Web服务器，而无需手动将其添加到身份验证头中，则您将面临CSRF攻击。@TrevorWard请阅读我的问题。cookie不包含令牌。cookie只包含令牌的附加签名，对cookie的任何检查都只是对令牌的附加检查，令牌必须正常发送。如果攻击者通过XSS（因为它不仅仅是http）获得您的令牌怎么办。然后他可以利用你的cookie检查系统进行CSRF攻击。虽然您的解决方案使入侵您的站点变得更加困难，但仍然存在一个漏洞。通过在存储令牌的cookie上设置HttpOnly，令牌将在每次请求时发送到cookie内部的Web服务器，服务器必须自动读取和处理它。CSRF攻击的工作原理是使您的浏览器通过其身份验证cookie（在本例中是包含令牌的cookie）发送恶意请求。如果您的令牌在cookie中自动传递到Web服务器，而无需手动将其添加到身份验证头中，则您将面临CSRF攻击。@TrevorWard请阅读我的问题。cookie不包含令牌。cookie只包含令牌的附加签名，对cookie的任何检查都只是对令牌的附加检查，令牌必须正常发送。如果攻击者通过XSS（因为它不仅仅是http）获得您的令牌怎么办。然后他可以利用你的cookie检查系统进行CSRF攻击。虽然您的解决方案使入侵您的站点变得更加困难，但仍然存在一个漏洞。