绕过混合内容警告 - 在安全的页面加载不安全的内容

来源链接：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 试图渲染另一个不安全的 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 并不有效。也许另有途径，但我在此停顿，我知道攻击者仍然有简单的方法来达到他们的恶意目的。