我只是在阅读 OWASP 的 JWT 备忘单的“令牌劫持”（https://cheatsheetseries.owasp.org/cheatsheets/JSON_Web_Token_Cheat_Sheet_for_Java.html#token-sidejacking）
目前我不明白推荐的预防措施如何真正解决问题。
解决方案是添加一个上下文并将这个上下文（例如一个随机值）作为 Cookie 以及 JWT 的一部分（然后经过哈希处理）发送。
但是，如果攻击者能够通过执行 XSS 攻击并访问 sessionStorage 来窃取 JWT，那么攻击者也可以发送 XHR 请求，因此 Cookie 会自动发送。如果攻击者能够嗅探网络流量，则攻击者也拥有 Cookie 值。我能想到的唯一情况是，如果攻击者可以访问存储 JWT 的某种日志，但这将是另一个（或更多）漏洞。
我错过了什么？谢谢
如果攻击者能够通过 XSS 攻击窃取 JWT 并访问 sessionStorage，则攻击者还可以发送 XHR-requests，因此 Cookie 会自动发送
该解决方案使用SameSite cookie。它们不会被发送到攻击者的服务器。
如果攻击者能够嗅探网络流量，则攻击者也拥有 Cookie 值。
您正在描述一种攻击，其中攻击者嗅探您的网络流量，然后在他们发现冒充您时使用。
大多数安全分析师认为 TLS（即 HTTPS）足以防止这种情况。流量从您的浏览器一直加密到您正在与之交谈的网络服务器（理论上您的请求可能会反弹并在站点的后端基础架构中以明文形式记录，但这需要进入站点的后端网络）
我必须同意你的观点，我也在努力想出一个场景，即该建议实际上可以做任何事情。
如果攻击者可以拦截您的 JWT，那么您会认为他们也可以获取 cookie。
如果他们可以将恶意 javascript 注入页面并读取浏览器的本地存储，那么您会认为他们也可以发送 GET / POST 并自动附加 cookie。
在 OWASP 的实现示例中，它们将用户上下文存储在Secure、HttpOnly、Samesite cookie 中。这有助于防止攻击者使用 XSS 读取此 Cookie 值。