Question

我以编程方式创建一个html报告，分为两个框架。如果用户然后单击右侧框架上的超链接，则该框架将替换为该页面的内容。

这很好但现在当我尝试链接到任何Discogs发布页面，例如this one时，它没有加载它

我注意到Discogs已经转移到安全的http，我想知道这是不是问题。虽然我可以转到其他https页面，例如Acoustid one 没问题。

如果我使用 target =“_ blank”在新标签页中打开第一个链接，那么它可以正常工作，但这不是我想要的。

Answer 1

您可以通过在Chrome中打开开发者工具来查看此问题的根本原因。如果我的问题正确，我会在简单的HTML页面中重现它：

<html>
<body>
    <iframe src="https://www.discogs.com/release/1000"></iframe>
</body>
</html>

这不是HTTP的问题。消息说：

Refused to display 'https://www.discogs.com/release/1000' in a frame because it set 'X-Frame-Options' to 'SAMEORIGIN'.

这意味着Discogs阻止在discogs.com之外的其他来源的帧中显示其内容。你无法做任何事情。

Answer 2

更新＃1

浏览器安全模型的基础是同源策略，它可以保护网站彼此。本教程中逐步提供了完整的详细信息示例：Security in Depth: Local Web Pages

简而言之，

如果网页来自您的本地文件系统而不是来自   互联网？如果您的浏览器，请考虑以下假设攻击   没有限制本地页面的力量：


您收到来自包含网页的攻击者的电子邮件   作为附件，您下载。

您可以在浏览器中打开现在的本地网页。

本地网页会创建一个<iframe>来源   https://mail.google.com/mail/。

由于您已登录Gmail，因此框架会加载邮件   你的收件箱。

本地网页通过使用来读取框架的内容   用于访问frames[0].document.documentElement.innerHTML的JavaScript。   （Internet网页无法执行此步骤，因为   它来自非Gmail来源;同源政策会   导致读取失败。）

本地网页将收件箱的内容放入   <textarea>并通过表单POST将数据提交给攻击者   网络服务器。现在，攻击者拥有您的收件箱，这可能对您有用   发送垃圾邮件或识别盗窃行为。

Gmail无法阻止此次攻击。   因此，浏览器通过在上面进行各种步骤来防止它   场景很难或不可能。

LocalLinks Addon uses NEW TAB to open iframe local file:

允许在http（s）：// scheme
加载的页面上打开file：//链接
Chrome的安全模型可阻止/阻止用户使用   当用户选择（左键单击）链接时打开file：//链接，或   选择在新窗口中打开它们（中间单击）。加载这个   扩展名将允许您在显式时关注file：//链接   选择它们（左键单击/中键单击）。它将是HTML元素   以下是<a href="file://server/share/file.txt">或<a href="file://c:/localdiskfile.txt">。

注意：它无法加载图片（例如<img src="file://..." />）！

要在同一标签中打开链接，请使用鼠标左键。

要在新的背景选项卡中打开链接，请使用鼠标中键。

此扩展程序是在Firefox的LocalLink附加组件之后建模的。

读   http://blog.chromium.org/2008/12/security-in-depth-local-web-pages.html

此版本的更改：+尊重目标=＆＃34; _blank＆＃34;属性   左键单击

完整的更新日志见   http://code.google.com/p/locallinks/wiki/CHANGELOG

还有另外两种类型的安全问题。

从您的http服务器调用带有https的iframe。
使用https服务器中的http调用iframe。

Mozilla基金会在此提供了很多详细信息：https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy

来自

的同源政策

同源策略限制从一个源加载的文档或脚本如何与来自另一个源的资源交互。它是隔离潜在恶意文档的关键安全机制。

原产地的定义

如果两个页面的协议，端口（如果指定了端口）和主机相同，则两个页面具有相同的来源。下表提供了与URL http://store.company.com/dir/page.html的原点比较示例：

--------------------------------------------------------------------------------
                   URL                           | Outcome |    Reason         |
--------------------------------------------------------------------------------
http://store.company.com/dir2/other.html         | Success |                   |
--------------------------------------------------------------------------------
http://store.company.com/dir/inner/another.html  | Success |                   |
--------------------------------------------------------------------------------
https://store.company.com/secure.html            | Failure | Different protocol|
--------------------------------------------------------------------------------
http://store.company.com:81/dir/etc.html         | Failure | Different port    |
--------------------------------------------------------------------------------
http://news.company.com/dir/other.html           | Failure | Different host    |
--------------------------------------------------------------------------------

Why you should not mix http and https when using iframes?

如何运作？

如果您的网页协议是http，请使用iframe内的http页面。
如果您的网页协议为https，请使用iframe内的https页面。

但你为什么不这样做？

1。 https with http iframe

让我们从您不应该做的那个开始：您的页面是https，您的iframe页面是http。这种情况被称为＆＃34;混合活动内容＆＃34;并被越来越多的浏览器阻止。

我从Firefox的开发者那里找到了关于这个主题的一个很好的描述： https://blog.mozilla.org/tanvi/2013/04/10/mixed-content-blocking-enabled-in-firefox-23/

您可以找到以下内容：Firefox和Internet Explorer考虑使用混合活动内容框架，而Chrome会考虑框架混合被动内容。这意味着Firefox和Internet Explorer会阻止iframe，而Chrome还没有（还）。

2。使用https iframe

另一种方法是将带有https页面的iframe包含在http页面中。

这是你可以做的但不推荐的方法（见下面原因）！如果您真的没有别的办法，请尝试它是否适用于所有主流浏览器。在Cookie或会话处理方面，我已经有了副作用用户！

下一部分来自HTTP and HTTPS iframe：

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

攻击者可以很好地替换您提供的内容：

<iframe src="https://your.legitimate.example/loginframe" width="300" height="150">

使用：

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

甚至：

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

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

所以我希望你现在不再混合内容了;）。

如果您仍然真的想要这样做：默认情况下，外部解决方法不适用于此设置，因为Javascript是从被阻止的http域加载的！所以要实现这个目标，你需要

启用＆＃34;使用发布消息进行通信＆＃34;关于＆＃34;外部解决方法＆＃34;标签。
将生成的ai_external.js复制到https域并从那里包含它！每次使用＆＃34; save＆＃34;更改内容时，请记得复制ai_external.js。管理中的图标。

有关详情，请点击此链接：https://stackoverflow.com/a/25189561/2293534

Answer 3

您可以使用iframe沙箱帮助测试解决问题：

允许-同源

Link

在框架内打开https页面是否有问题

3 个答案: