来源链接：https://www.brokenbrowser.com/loading-insecure-content-in-secure-pages/

原作者：MagicMac

译：Holic (知道创宇404安全实验室)

毋庸置疑，当今网络正在向 HTTPS（安全）内容发展。重要的域名现在他们已经将证书准备好了，他们的站点应该是有效且安全的。但是你是不是很好奇：到底能安全到何种程度？显然，通过 HTTPS 提供的内容是可以抵御中间人攻击（MITM），网络嗅探/篡改等方面的攻击的。但是你有没有想过， HTTPS 协议是否保护终端用户免受其他方面的威胁？答案显然是肯定的。

如我们所知，攻击者目前使用了广泛的渠道提供他们的恶意 payload ，恶意广告便是其中之一。他们购买廉价的广告空间展示显眼的广告，但是在这些 banner 的深处，我们可以发现混淆的恶意代码。其实，我们已经看到过坏人曾经是如何检测用户是否属于潜在受害者（注：参考 http://paper.seebug.org/87/ ），或者检测出她是个分析人员的。如果键盘背后的人是一个不够精明的用户，攻击者会提供完整的恶意 payload ，否则他们只是简单地伪装成合法产品的广告。

混合内容警告

攻击者现在有个问题，因为他们的技巧只在不安全的页面有效，而浏览器默认情况下不会在安全的网站呈现不安全的内容。具体来说如果攻击者强行通过 HTTPS 加载他们的代码，他们的很多技巧（比如检测文件系统）将无法实施。考虑一点： IE/Edge (和其他浏览器) 拒绝从安全的域(HTTPS)加载不安全的内容 (HTTP) .

现代浏览器默认情况下不会渲染混合内容（来自安全站点的不安全数据）。如果我们浏览 HTTPS 网页，浏览器会拒绝加载不安全的内容（例如，里面有个 banner 的 HTTP iframe）。Internet Explorer 将向用户发出“显示所有内容”（重新加载主页并显示所有混合内容）的警告。

Edge 还会阻止内容，但除非用户使用 devtools-console 窗口查看，否则不会显示警告。此外，如果不安全的内容来自 iframe，则会显示混乱的错误信息。

允许加载图片

一个有趣的例外是，所有浏览器允许无限制加载并渲染不安全的图像。换句话说，如果攻击者已经在网络中进行嗅探，他们将能够在运行中浏览并替换图片，但这并不代表对最终用户的真正威胁。一年前 Eric Lawrence (aka: Internet Hero) 写了一篇博文很清晰地解释了为什么 IE 的团队允许不提示警告的情况下加载不安全的图像。这是很有道理的：许多网站使用 HTTP 协议从外部加载它们的图像，或更糟的情况，它们在资源中硬编码了指向本地图像的 HTTP 协议，但内容本身（html/scripts）是安全的。所以，它们决定允许图像标签加载一个没有警告的渲染器，除了地址栏右边的小挂锁会消失。

这是地址栏在 IE 上加载不安全图片之前和之后的样子。注意主地址栏的安全协议根本不会改变。我用红圈标记了锁，这样更容易看到。

同样的事情发生在 Microsoft Edge 上，但锁的图标在左边。如果你想试验一下，可以在此试一下。

有件有趣的事要记住，两个浏览器都认为伪协议（res: mhtml: file:）是不安全的，所以如果我们尝试使用这些协议加载内容，都会失败，就像普通 http 在 https 中那样。

These iframes won't render anything if the main page is secure/https

<iframe src="http://">
<iframe src="res://">
<iframe src="file://">
<iframe src="mhtml://">
<iframe src="mhtml:res://">

使用伪协议的行为

你可能在想，HTTPS 与这些奇怪的 mhtml: 和 res: 协议有什么关系？这些奇怪的协议被使用者用来加载硬盘中的文件，用于检测本地文件的存在，如果主页是安全的，他们将有一个大问题：IE 将拒绝解析这些协议。因此不要使用他们的技巧！考虑一下：安全的网页不仅帮助我们免受 MITM 攻击，而且作为副作用防止了攻击者的很多小把戏。

谨记：当攻击者想要检查用户在她的文件系统中是否有特定文件，他们往往使用熟知的技术来利用 mhtml/res/file 协议。 如果你从来没有见过相关技巧，请看这个技巧相关的博文，但这里需要注意的是：现代浏览器默认不允许“混合内容”，而且许多技巧将在 HTTPS 中失效。

强制加载内容

那么现在我们知道了攻击者的意图，是时候验证他们尝试的技巧了：绕过这些警告。

之前我们知道了在没有用户交互的情况下渲染内容的规则（image 标签）存在着例外情况，我尝试加载源是图像的 IFRAME （而不是 IMG），但并没有成功。然后整了点 EMBED 和 OBJECT 元素（二者皆可渲染 html）也没真正成功。最后，我决定使用常规 IFRAME ，但是通过使用服务器重定向而不是直接使用不安全的 URL 设置其 location 属性。这似乎有效，内容终于加载上了。

Main page should be secure/https

The iframe below renders an insecure (http) bing.com
<iframe src="https://www.cracking.com.ar/redir/redir.php?URL=http://www.bing.com">

作为一名研究人员上面这个发现看上去很有趣，但从攻击者的角度看却毫无用处。我们已经可以在不经过用户同意的情况下加载混合内容，但那个警告却会引起用户警觉。出现警告是因为加载了不安全的内容（bing.com确实是通过HTTP加载的），所以，攻击者绝对不会使用这种会引起用户警觉的手法。 （本段翻译有疏漏，现已补充，多谢 @psrain 反馈指正）

当不安全的 bing.com 试图渲染另一个不安全的 iframe 内部内容时，问题便发生了。换句话说，iframe 的子元素也需要是安全的或者是绕过的，相同的技巧也需要进行重定向。但是这并没什么用，因为攻击者需要 IE 伪协议（mhtml: res: 和 file:）来实现他们的技巧，而 IE 不接受服务器重定向至那些协议。那么我们需要有更好的选择。

绕过警告信息

为了找到绕过警告信息的方法，我偶然发现了解决方案。我很惊讶，这个技巧是那么基础的东西：在不安全的 iframe 中放一个 document.write 就够了。可能这么简单吗？一看便知：

Main page should be secure/https

The iframe below renders an insecure (http) page which does a document.write
<iframe src="https://www.cracking.com.ar/redir/redir.php?URL=http://unsafe.cracking.com.ar">

The HTML code in the iframe is quite simple:
<script>document.write()</script>

一旦加载了不安全的内容和 document.write ，iframe 就可以自由加载不安全的内容了，而且无需重定向。换句话说，这时攻击者可以加载 mhtml/res 协议，无限制施展他们的技巧：IE 不知道这些内容是正在被渲染的，每个嵌入的 iframe 将加载无误。

在线 PoC 地址

Edge 浏览器受该重定向技巧的漏洞影响，但 document.write 的方法并不奏效。也许另有途径，但我在此停顿下来，我知道攻击者仍然有简单的方法来达到他们的恶意目的。