为什么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来避免使用{{ 1}}，使用iframe的任何解决方案都是毫无疑问的）

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

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

  

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

正确。这就是为什么

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

  

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

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

1. 使用Allow Skipping User Consent 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. 此外，将标头SameSite设置为仅允许安全连接，以防止中间人覆盖来自子域的CSRF cookie