时间戳

首页 > 解决方案 > 将 JWT 令牌存储在非 HttpOnly Cookie 中以结合指纹识别实现多选项卡支持

cookies - 将 JWT 令牌存储在非 HttpOnly Cookie 中以结合指纹识别实现多选项卡支持

问题描述

我在https://cheatsheetseries.owasp.org/cheatsheets/JSON_Web_Token_for_Java_Cheat_Sheet.html上阅读了有关保护基于 JWT 的服务的内容。在本指南中，它告诉如何在客户端处理 JWT 令牌

由浏览器自动发送（Cookie 存储）。

  1. 即使重新启动浏览器也可以检索（使用浏览器 localStorage 容器）。
  2. 在 XSS 问题的情况下检索（JavaScript 代码可访问的 Cookie 或存储在浏览器本地/会话存储中的令牌）。

如何预防

  1. 使用浏览器 sessionStorage 容器存储令牌。在调用服务时将其添加
    为带有 JavaScript 的承载 HTTP 身份验证标头。

  2. 将指纹信息添加到令牌中。通过将令牌存储在浏览器 sessionStorage 容器中，它会将令牌暴露给
    通过 XSS 攻击被盗。但是，添加到令牌中的指纹会
    阻止攻击者在其机器上重复使用被盗令牌。要为
    攻击者关闭最大的利用面，请添加浏览器内容安全策略以强化
    执行上下文。

OWASP 提供的解决方案限制

问题在于，如果用户在同一浏览器的另一个选项卡中输入相同的 URL，则不应向他显示登录页面，而应将其定向到主屏幕而无需任何登录过程。要解决这个问题。我遵循了以下方法。顺便说一句，我正在使用刷新令牌来支持滑动会话

  1. 用户输入登录用户名和密码
  2. 验证登录凭据后，访问令牌存储在非 httponly、secure、samesite cookie 中，刷新令牌存储在 secure、samesite、httponly cookie
  3. 通过嵌入令牌信息的不同用户上下文的组合添加指纹值。此指纹 cookie 值也存储在安全、相同站点、httponly cookie 中，并且在提供给客户端的每个新访问令牌上都会更改。
  4. Fingerprint 值是为了防止 tokensidejacking。即使访问令牌是从 cookie 中窃取的。由于指纹信息丢失，攻击者将无法使用它
  5. 在每个请求中，浏览器客户端将需要通过获取 cookie 中存在的访问令牌来将访问令牌作为标头中的不记名令牌发送。这既可以作为 CSRF 预防机制，也可以作为用户身份验证机制。
  6. 如果令牌过期，浏览器将调用刷新令牌 URL，并且由于刷新令牌 cookie 已经存在，服务器将自动获取刷新令牌并提供新的访问令牌和刷新令牌。第 2 步再次发生

那么这种方法安全可靠吗？由于应用了 tokensidejacking 的对策。我应该担心将访问令牌存储在非 httponly cookie 中吗？

注意：我不将访问令牌和刷新令牌都存储在内存中 javascript 变量中的原因是，这些令牌需要在托管在同一域上的多个应用程序之间共享。

标签： cookiesoauth-2.0jwtspring-security-oauth2spring-oauth2

解决方案

推荐阅读