使用 Window.postMessage 将身份验证令牌发送到嵌入式应用程序

Question

考虑以下场景。

网站 foo.com 有一个应用商店。开发人员可以在那里注册他们的应用程序。一个应用由 id、logo、url 和一组权限组成。

用户可以浏览应用商店并激活应用。通过激活应用程序，他们接受该应用程序可以使用给定权限代表他们执行操作。激活应用程序会在他们的菜单中为他们提供一个带有应用程序徽标/ID 的图标。它还生成并保存具有所述权限的身份验证令牌。

当他们点击应用程序时，相应的应用程序网址会加载到 iframe 中。到目前为止，一切都很好。现在，该应用程序需要一种方式来实际代表 foo.com 上的用户执行操作。为此，父窗口使用 window.postMessage 将身份验证令牌发送到包含应用程序的 iframe。

应用 url 的 html 必须包含一个小的 JS sn-p 侦听来自父窗口的身份验证令牌。一旦获得令牌，它就可以将其保存在 cookie/会话存储/任何东西中，然后继续呈现应用程序并代表用户进行调用。

（注意：我没有指定身份验证令牌。它可以是 oAuth 访问令牌或 JWT 或其他。）

现在的问题是：这是一个可怕且令人难以置信的不安全想法？

另一种“标准”方法是让应用程序 url 启动一个 3 腿 oAuth 身份验证方案，这会将用户重定向回 foo.com（在 iframe 内，所以现在 foo.com 在 foo.com 内）接受应用程序（诚然，您可以自动完成，因为用户已经接受了应用程序），然后 foo.com 将使用授权码重定向回应用程序 url，它可以交换访问令牌。

我认为建议的 postMessage 流程更简单、更清晰。我没有看到哪些缺点？

显然，这不是 3rd 方应用识别的灵丹妙药。仅在授权服务器控制第三方应用加载的情况下有效。

Answer 1

如果 javascript 可以访问身份验证令牌，那么它们很容易受到 XSS 攻击。这就是为什么 auth cookie 具有阻止 JS 与它们交互的 httpOnly 标志的原因。

对第三方应用的 XSS 攻击可能会泄露该特定第三方应用的应用身份验证令牌。

对 foo.com 的 XSS 攻击可能会泄露所有应用身份验证令牌。

标准的 3 腿 oAuth 流程以第 3 方后端向浏览器发出某些内容作为相应的 oAuth 凭据来验证浏览器而结束。如果这是一个 httpOnly cookie，那么它会更安全，因为它不易受到 XSS 攻击。

此外，即使 XSS 风险是可以接受的，您仍然会遇到 CORS 问题，因为浏览器将位于向 foo.com 发出请求的第三方域中