webbrowser只对浏览器外应用程序以及在_IE 一个漏洞遍布的浏览器（三）

本质上，对象在较旧的文档模式中呈现为独立实体，但在较新的文档模式中呈现为iframe。无论如何，内部都是WebBrowser控件，Trident引擎暴露的成员属性都是相同的。

但是当我们关闭兼容性代码时

继承的窗口成员

让我们回顾一个较旧的documentMode并找到一种方法来利用这个混乱错误，这似乎并不是那么糟糕，因为跨域限制仍然存在，并且X-FRAME-OPTIONS标题非常有效。像window.name这样的成员是由对象继承的(对象继承了它的父对象的名称)，但除了不安全地使用window.name在iframe中传递信息的特定广告技术之外，但是这并不是最恶心的情况。

话虽如此，至少有一个真正导致麻烦的继承对象：位置。在对象标记内，location.href将返回主(顶部)窗口的位置。下面的代码呈现对象，其源指向3.html，但是当我们检索其位置时，它是会返回顶部并跳像指定的那个文件的。

同样，这个混乱错误也没用，因为我们仍然在同一个域上。即使我们可以检索 - 也会感觉到很乱 - 顶部的位置，只要我们在同一个域上，事情就不会那么让人感觉很舒服。顺便说一下如何利用这些bug，我试了几分钟来改变对象的位置，但没有成功。如果你想研究这个我建议你去更深入了解其内核以及相关浏览器的技术实现源代码，因为我相信它应该是可能的。无论是，在试图实现UXSS一个有趣的错误偶然让我发现：当对象被注入onbeforeunload我们得到的是没有显示顶部的html，当前写入地址栏的内容。

换句话说，如果我们在用户离开主页时检索对象的location.href，我们将能够知道在地址栏中输入了什么，或者，如果用户点击链接，我们就会知道浏览器要访问的链接的地址。

出于测试目的，我们将中断新站点的加载并向用户显示URL。当然，攻击者只需回传地址并加载网站，无论如何都要对用户透明。

后面让我们在用户离开时做一个简单的document.write对象。