为何auth0建议不将令牌存储在localStorage中？

Question

Auth0提供了大量资源列表，这些资源描述了认证的最佳实践。其中不断有建议不要使用localStorage作为存储（JWT）令牌的手段。

• https://auth0.com/docs/security/store-tokens#don-t-store-tokens-in-local-storage
• https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/HTML5_Security_Cheat_Sheet.md#local-storage
• https://github.com/auth0/docs/issues?utf8=%E2%9C%93&q=localstorage

我发现这些问题有几个问题：

• 有一个强有力的假设，即JWT令牌是攻击者不能通过XSS访问的敏感信息。
  • 从我的角度来看，访问令牌本身并没有扩大攻击范围。如果攻击者控制了受害者的浏览器，则他们可以使用令牌从受影响的浏览器本身执行调用。
  • 访问令牌通常具有相当短的到期时间，并且可以将它们固定在浏览器中，从而减少了在XSS上下文之外使用它们的机会。
• Auth0建议从其SDK使用auth0.getTokenSilently()来获取令牌，但据我所知，攻击者没有任何理由不能自己调用​​此方法（即使用现有客户端注入另一个sdk脚本）键，然后从那里调用getToken），从而获得令牌的方式几乎与将其存储在localStorage
中的方式相同
• 我知道XSS无法访问令牌的唯一方法基本上是使用httpOnly cookie，但是它自己创建了新的向量（CSRF），并且仍然无法阻止攻击者从受影响的内部调用api浏览器。

因此，我完全同意OWASP的建议，不要在localStorage中存储敏感数据，我从不考虑在其中存储信用卡号或密码，甚至个人数据。但这仅仅是因为这些事情会使攻击者扩大攻击范围（访问银行帐户，并尝试在其他应用中重用用户的密码，等等）。但是我很难看到accessTokens对此有何影响。

Answer 1

尽管我对Auth0的实现，功能和设计决策了解不多，但从我对OAuth2和安全性的一般理解中，我可以尝试将各个方面联系起来。

---

单个建议本身并不能提供足够的安全性或所需的功能，但是当与其他相关建议结合使用时，我们可以达到所需的安全性和行为水平。

让我们来谈谈你提出的观点。

从我的角度来看，访问令牌本身并没有扩大攻击范围。如果攻击者可以控制受害者的浏览器，他们可以使用令牌从受影响的浏览器本身执行调用]

localstorage的问题是：

1. localStorage和sessionStorage不跨子域共享。这是SSO功能的显示止挡器（有些解决方案使用iframe，但看起来更像是变通方法，而不是一个好的解决方案。当使用响应标头X-Frame-Options来避免使用iframe进行点击劫持攻击时，用iframe表示的任何解决方案都是毫无疑问的）

2. XSS可以将访问和/或刷新令牌发送到攻击者控制的远程服务器，从而允许攻击者模拟用户

注：在第2点中提到的漏洞可以通过使用Sender Constrained Access Tokens方法来缓解，其中客户端必须证明他们确实拥有令牌。另一种选择是OWASP中提到的fingerprint approach，它需要一个cookie。但是，似乎Auth0并没有实现这些功能。因此，避免使用localstorage的建议是有意义的。

Auth0建议从其SDK使用auth0.getTokenSilently（）来获取令牌，但据我所知，没有任何理由使攻击者无法自行调用此方法

正确。这就是为什么

1. 我们首先需要遵循OWASP XSS prevention guidelines来减轻XSS的风险。
2. 此外，getTokenSilently()方法要求您在仪表板的API设置中启用Allow Skipping User Consent。尽管我对此没有特定的指导原则，但是我认为如果将令牌存储在cookie中，则不需要启用此选项，从而消除了滥用该方法的可能性。

我知道XSS无法访问令牌的唯一方法基本上是使用httpOnly cookie，但是它自己创建了新的向量（CSRF），并且仍然无法阻止攻击者从受影响的内部调用api浏览器

是。但是您可以使用以下一种或多种方法来缓解这种情况：

1. 使用SameSite Cookie。请参考文档here。如果浏览器不支持SameSite cookie，请遵循以下另一种方法
2. 状态变量（Auth0使用它）-客户端将生成并随每个请求传递一个加密强度高的随机随机数，服务器将随其响应返回回显，从而允许客户端验证随机数。在Auth0 doc中有解释。
3. 使用具有加密强随机值的CSRF cookie，以便每个AJAX请求读取cookie值并将cookie值添加到自定义HTTP标头中（不应该对状态进行任何修改的GET和HEAD请求除外）。由于CSRF由于相同的原始策略而无法读取任何内容，并且基于利用不安全的HTTP方法（例如POST，PUT和DELETE），因此该CSRF cookie将减轻CSRF的风险。所有现代SPA框架都使用这种使用CSRF cookie的方法。提到了Angular方法here
4. 始终检查引荐来源标头，并且仅在引荐来源为可信域时才接受请求。如果没有引荐来源标头或域名不在白名单中，则只需拒绝该请求即可。使用SSL / TLS时，通常会存在引荐来源网址。登陆页面（主要是信息性的，不包含登录表单或任何受保护的内容可能会稍微放松一些，并允许缺少引荐标头的请求
5. TRACE HTTP方法应在服务器中被阻止，因为该方法可用于读取httpOnly cookie
6. 此外，设置标题Strict-Transport-Security: max-age=<expire-time>; includeSubDomains​仅允许安全连接，以防止任何中间人覆盖子域的CSRF cookie