Get best of the week

关于在浏览器中存储JWT令牌


JWT开放标准于2015年正式出现（rfc7519），具有有趣的功能和广阔的前景。正确存储Access令牌对于在现代Web上构建授权和认证系统至关重要，在现代Web上，使用SPA技术构建的网站越来越受欢迎。

令牌的不正确存储会导致其被盗并被攻击者重新使用。

那么在哪里存储呢？


考虑在浏览器中存储JWT Access令牌的主要选项：

  1. 本地存储/会话存储 -该方法不安全，容易受到XSS之类的攻击，特别是如果您连接来自第三方CDN的脚本（添加完整性属性不能保证100％安全），或者不确定所连接的脚本是否不能“合并”来自储物设施在一边。此外，如果在选项卡之间可以使用“本地存储”，则“会话存储”仅在一个选项卡中可用，而在新选项卡中打开站点只会导致新一轮的访问令牌/授权。
  2. , , fetch . – .
  3. Cookies. «» cookie sessions. Access cookie CSRF. XSS . CSRF Cookie SameSite Strict– , , credentials, CSRF .
    – Access JS httpOnly, Secure .

    重要的一点是仅为域/路径api设置cookie，以便对公共静态变量的请求在标头中不包含开销。

结果是什么？


Cookies正确使用后，是目前存储JWT Access令牌的合适且最安全的解决方案，并且必须遵循以下规则：

  1. 为域/路径API安装，以避免在请求静态文件（公共图像/样式/ js文件）时产生开销。
  2. 带有安全标志（仅通过https进行传输）。
  3. 具有httpOnly标志（因为无法从JavaScript访问）。
  4. SameSite属性必须严格，以防止受到CSRF攻击，如果到API的转换不是来自cookie中设置的域，则禁止cookie的传输。

在服务器端，还应该对其进行配置：

  1. 内容安全策略 -限制受信任的域以防止可能的XSS攻击
  2. X-Frame-Options标头可防止点击劫持攻击。
  3. X-XSS-Protection-强制浏览器的内置保护机制免受XSS攻击。
  4. X-Content-Type-Options-防止替换MIME类型。

遵守这些措施，以及频繁循环访问/刷新令牌，应有助于确保站点的高安全性。

局限性


尽管许多流行的浏览器都支持SameSite属性，但有些浏览器不支持或部分支持它（Hello IE和Mac的Safari）。对于这些情况，您需要回退到CSRF令牌。在这种情况下，还必须与对API的请求一起传输CSRF令牌。服务器必须考虑用户的指纹来生成正确的CSRF令牌，以最大程度地减少替换它的可能性。

More articles:


All Articles