IE地址栏的信息是如何泄露的
导语：IE浏览器到底有多不安全 你还在用IE浏览器吗？现如今浏览器的种类越来越多，IE浏览器几乎已经快被人们遗忘了。虽然如此对IE浏览器的安全研究还是非常有必要的，因为目前还有很多操作是基于它的，另一方面，IE浏览器最近几年也在推陈出新
IE浏览器到底有多不安全
你还在用IE浏览器吗？现如今浏览器的种类越来越多，IE浏览器几乎已经快被人们遗忘了。虽然如此对IE浏览器的安全研究还是非常有必要的，因为目前还有很多操作是基于它的，另一方面，IE浏览器最近几年也在推陈出新，不断利用各种方法加强安全性。
但你要知道，Windows目前仍然是被全球黑客攻击最多的操作系统，所以IE浏览器的安全性仍备受质疑。例如，最近肆虐于IE的僵尸脚本漏洞（zombie script bug），虽然该漏洞早在2月份就被披露了，但截至发稿时仍未被修复，你可能会认为这是一个小漏洞影响不大，但我要诉你的是，该漏洞会让让所有IE用户都变为僵尸用户。这样，黑客就可以利用该漏洞驻留在受害者的浏览器中，当受害者浏览不同的网站时，黑客就会有足够的时间来实施诸如滥用用户的CPU进行数字货币挖掘的恶意行为。此外， IE的阻止弹出窗口功能已经彻底沦为了摆设……虽然IE的问题层出不穷，但我建议大家还是先别着急抛弃它。
在我看来，微软也正在试图摆脱IE所带来的负面效应，让用户使用全新的Edge浏览器。不过，根据Netmarketshare的统计，目前IE的用户占比17％，而Edge的用户占比仅为6％，显而易见，IE仍比Edge受欢迎的多。
虽然我坚信IE应该具备像Edge那样得到安全技术，但显然这是妄想。就拿近日发现的一个IE漏洞来说吧，你都想象不到黑客能利用该漏洞来监控用户IE地址栏的输入内容。
漏洞介绍
当受害者的IE浏览器脚本执行HTML <object>标签时，黑客利用html标签就可以获取位置对象的焦点状态并让其返回主位置（main location）而非当前的位置，确切地说，它将返回写入地址栏文本的位置。有兴趣的读者可以点此观看视频，以直观地了解黑客是如何读取用户输入到IE地址栏里的内容的。
对象和文档模式
对象标签的具体运行取决于documentMode的渲染方式，例如，如果用户在网页页面的开头添加兼容性的HTML <meta>标签，那它的外观和运行就像一个HTML <iframe>标签，也就是说，此时，黑客可以让受害者的页面误认为该标签是顶层窗口。
<head> <!-- COMPATIBILITY META TAG --> <meta http-equiv="X-UA-Compatible" content="IE=8" /> </head> <object data="obj.html" type="text/html"></object>
在上面的代码中，“obj.html”是在对象内部被渲染的，并且被渲染的内容被封装在与iframe类似的代码块中，然而，虽然在窗口对象与顶层对象进行比较时返回值为true，但是它并非顶层窗口。看看在HTML <object>标签内执行的代码，可以看出，虽然代码确定window == top，但显然这是黑客做得手脚。
你可以点此，详细查看在IE上进行的测试。
由于受害者的<object>标签误认为它是顶层窗口，甚至其他像frameElement这类的对象也总是返回null，目前来看，这种对象行为只发生IE上的顶层窗口。
以上是我在添加了兼容性的HTML <meta>标签的情况下进行的测试，现在我会尝试在没有兼容性标签的情况下对具有相同的代码的对象进行测试。从下图可以看出，该对象已经知道了它所在的位置，并且其行为类似于iframe。
<!-- COMPATIBILITY META TAG REMOVED --> <object data="obj.html" type="text/html"></object>
你可以点此，详细查看在IE上进行的测试。
本质上，该对象在较旧的文档模式中会被渲染为一个独立的个体，但如果是在较新的文档模式中则会被渲染为一个iframe。无论如何，二者的内部都用的是WebBrowser控件，Trident引擎暴露出的问题也是一样的。
IE窗口的对象继承攻击
再重新说一说documentMode，寻找一种利用这个混淆漏洞的方法，不过该漏洞并非像我想的那么强大，它还是存在跨域限制的，而且X-Frame-Options响应头运行的也很好，X-Frame-Options HTTP响应头是用来确认是否浏览器可以在frame或iframe标签中渲染一个页面，网站可以用这个头来保证他们的内容不会被嵌入到其它网站中，以来避免点击劫持。再比如window.name，它们是通过对象继承得到的（该对象会继承其父对象的名称），攻击者可以利用window.name+iframe跨域获取数据，一些广告技术商会利用该方法实施跨域信息传递。
另外一个由对象继承引起的漏洞，就是位置漏洞。在<object>标签内，location.href会返回主（顶层）窗口的位置。黑客会利用下面的代码将其攻击对象的源代码指向object_location.html，但是当我检索它的位置时，它返回的却是顶层窗口。
你可以点此，详细查看在IE上进行的测试。
不过要注意的是，只要在同一个域，这个混淆漏洞本身就是没有用的。即使我可以找到一个顶层的位置来利用该混淆漏洞，但只要在同一个域，还是没有任何实际效果。如果你想对该话题进行深入研究，我建议你可以尝试实现UXSS，毕竟，持久性是现实攻击中一切的关键。当对象被注入到onbeforeunload时，我得到的不再是顶级位置，而是浏览器的位置到或当前写入地址栏的内容。
换句话说，如果我在用户离开主页面的同时检索对象的location.href，我将能够知道他在地址栏中输入的内容，再或者，如果我点击链接，我将会知道浏览器要链接的地址。
为了达到我的测试目的，我只会中断新站点的加载并向用户显示URL。当然，在实际的攻击活动中，攻击者会直接回填地址并加载站点。实际上，在用户离开主页面时，直接执行document.write就行了。
window.onbeforeunload = function()
{
document.write('<object data="loc.html" type="text/html" width="800" height="300"></object>');
document.close();
}
并在合适的时机读取位置（onbeforeunload）。
document.write("Let me read your mind. You wanted to go here: " + location.href +);
这样，我就能在用户离开主页面时获取对象位置，进而监控受害者在地址栏中输入的内容。当然，对象位置不一定是一个完整的URL，例如，用户在地址栏中输入的是单词，那该单词将自动被转换为搜索查询URL（IE默认为Bing），不过，这并不影响对地址栏中输入内容的完整读取。
你可以点此，详细查看在IE上进行的测试。