Chrome 扩展中的 MSAL：安全令牌存储答案

【问题标题】：MSAL in Chrome Extension: Secure Token StorageChrome 扩展中的 MSAL：安全令牌存储
【发布时间】：2021-12-03 19:30:01
【问题描述】：

我们在 iFrame 中制作了一个 Chrome 扩展程序，以防止在访问 evil.com 时出现 XSS。扩展的目的是提供来自与被访问页面相关的 Web 服务的相关数据。该应用程序通过 MSAL 进行身份验证，并且当前将令牌存储在 sessionStorage 中。每个选项卡都需要自己的登录名，这是一种糟糕的体验，因此我们将使用 localStorage。我发现链接表明relative security 更适合 sessionStorage，尽管根本问题似乎是apply to both。实现我们的用例的最佳实践是什么，攻击面是什么？谢谢。

-- 10/22 编辑--

在下面添加图表以帮助澄清。针对给定场景的具体问题是 MSAL.js：

我们的 iframed 应用或其本地存储缓存令牌是否容易受到主机网站中运行的任何内容的影响
在 MSAL 上使用 sessionStorage 与 localStorage 是否会带来任何安全问题？（localStorage 对我们的 UX 非常重要，因为 sessionStorage 访问任何网站/新标签都会开始新的登录过程）
我们是否应该考虑将任何 CSP 纳入我们的 MSAL 应用程序以进一步加强安全性？

【问题讨论】：

标签： local-storage xss msal msal.js

【解决方案1】：

在浏览器存储中存储令牌只是故事的一部分。 Azure AD 采取额外步骤来提高安全性。例如，分配给 SPA 的代币只有 1 小时的生命周期。然后有许多功能可以消除重放攻击，例如签名密钥轮换、多因素身份验证、持续访问评估等。这里的 API 还在授予访问权限之前验证访问令牌。最终，它在更高的安全性和更好的用户体验之间进行权衡。例如，会话存储更安全，但本地存储让您可以在选项卡之间进行单点登录。 MSAL.js 有一个内存令牌存储选项，并且正在努力提供一个安全存储选项。一般来说，SPA 并不意味着处理关键数据访问。例如，在这种情况下，您可能希望使用代表流程的 Web 应用程序或 SPA。正确实现的浏览器（又名用户代理）将不允许 iframe 内容泄漏到 iframe 之外。如果主文档（包含元素的文档）具有合适的样式并提示 iframe 包含不受信任的内容，则没有问题。当然，取模浏览器中的真正漏洞。简而言之，an 与 <a href> 一样安全。

【讨论】：

谢谢，露莎。我意识到我的问题有点过于笼统，现在已经对其进行了编辑，以便您可以更好地了解我的具体问题/问题。谢谢。