【问题标题】:HTTP and HTTPS iframeHTTP 和 HTTPS iframe
【发布时间】:2011-03-09 20:50:36
【问题描述】:

我正在创建一个小部件,我想允许其他人使用它。 iframe 是通过 HTTP 加载的 - 但我希望允许用户通过 HTTPS 登录。即通过 SSL 发送登录请求。

这在同源策略中是否允许?即场景是用户可以将我的 JavaScript 集成到他们的网站,小部件打开,我想允许他们通过 HTTPS 登录?

【问题讨论】:

标签: http iframe https cross-domain


【解决方案1】:

在通过纯 HTTP(或混合内容)提供的页面中嵌入带有通过 HTTPS 提供的内容的 iframe 通常是不好的做法。原因是用户没有很好的方法来检查他们是否正在使用他们想要的 HTTPS 站点(除非用户真的想检查页面的来源)。

攻击者可以很好地替换您提供的内容,如下所示:

<iframe src="https://your.legitimate.example/loginframe" />

与:

<iframe src="https://rogue.site.example/badloginframe" />

甚至:

<iframe src="http://rogue.site.example/badloginframe" />

这对于用户来说很难检测到,并且会破坏您通过启用 HTTPS 登录来尝试实施的安全措施。

【讨论】:

    【解决方案2】:

    @Bruno - 我同意,但我想指出,即使检查页面的来源 - 要求很高 - 也可能不足以确保安全或正确/预期的目的地,因为这通常是 最初提供的源文本。除非我严重错误,否则可以使用页内甚至页外 javascript 代码轻松更改(如果有人真的想让它几乎无法找到,它本身可能会被混淆)。也就是说,如果用户有合适的浏览器,我认为他们可能能够 - 如果他们一开始就怀疑 - 检查 iframe 的来源以确定该代码的来源,然后确定他们是否信任该来源......这不是一个真正合理的期望。

    尽管所有这一切都可以通过适当的调试器和/或软件/DOM 检查器以及数字肘部油脂的良好帮助来确定,但 OP 不能合理地期望每个人都这样做(如果 任何人 )

    【讨论】:

    • 99.9% 的互联网用户不知道或懒得查看页面来源。我知道你怎么能说服我父亲检查源代码,更不用说使用调试器了。
    【解决方案3】:

    我做了一些测试。如果您使用 https 从 https 页面链接到另一个域,则需要有效的 SSL 证书。

    【讨论】:

      猜你喜欢
      • 2017-09-06
      • 1970-01-01
      • 1970-01-01
      • 2014-04-17
      • 2011-09-25
      • 2015-08-07
      • 1970-01-01
      • 2015-12-04
      • 2018-12-30
      相关资源
      最近更新 更多