security - 如果提供程序和 RP 在同一个域中，在 iframe 中加载 OpenID 提供程序是不是一个坏主意？

Question

这里有很多问题，有人想在 iframe 中加载 OpenID 提供者的登录页面，而不是重定向并让提供者控制登录页面的整个外观。出于非常可靠的安全原因(主要是反网络钓鱼)，这是一个很大的禁忌，被禁止，并且大多数 OpenID 提供商拒绝在 iframe 中加载。

我曾遇到过在单个组织的网站和应用程序集中使用 OpenID 的情况。 OpenID 提供者有一个 RP 的白名单，并且只会响应那些 RP。希望根据哪个 RP 将用户发送给它，在提供商处广泛定制登录页面。 (如果也有强烈的安全论据反对这样做，我也想知道它们。)

对此提出的解决方案是简单地允许 RP 在 iframe 中显示登录页面，这样他们就可以在登录框周围放置任何他们想要的设计。在这种情况下，只有“用户名”“密码”字段和“登录”“忘记密码”“注册新帐户”按钮将托管在提供商处，页面的其余部分将位于 RP 并且仍然具有 RP 的地址标题栏。不是最优的，是的，但争论是“这是一个不同的子域，但相同的二级域，所以它仍然可以。”

我不明白这是怎么回事 - 不同应用程序的登录页面非常不同，仍然让用户更容易受到网络钓鱼和其他攻击。我的这个结论不正确吗？关于这个的每个问题似乎都是关于使用外部或公共(public)提供者，而我遇到的反驳是这些问题不适用于仅限于同一域上的站点的私有(private)提供者。

Answer 1

即使您扮演自己的提供者的角色，关于在 iframe 中使用 OpenID 的普遍担忧确实有一定的有效性。如果您的任何组件容易受到脚本注入(inject)的影响，则它们可能会危及您的用户凭据，因为您可以从父窗口访问 iframe 数据。

重定向的正常建议(可选地在 pop-up 中)将限制这种风险，因为攻击者现在需要注入(inject) OpenID 登录页面，您可能在该页面中没有脚本注入(inject)缺陷。