当脚本在object-html标签内执行时，位置对象将获得焦点并返回主位置，而不是它自己的位置。 确切地说，它将返回写入地址栏中的文本。在了解攻击者是如何读取用户输入到IE地址栏内的内容的，先应该知道以下信息。
1，关于对象和文档模式
对象标签的行为方式取决于documentMode的渲染方式。 例如，如果我们在页面的开头添加兼容性元标记的话，它的外观和行为就像一个iframe，但它会认为这是一个顶层窗口。
比如，“obj.html”在对象内部进行渲染，并且其内容被放入与iframe类似的方框中，然而，虽然在窗口对象与顶层对象进行比较时返回值为true，但是它并非顶层窗口。我们可以看一下在对象标签内执行的代码：虽然它认为window == top，但是事实并非如此。
2，在IE上进行测试
我们的对象认为它是顶层窗口，甚至其他frameElement之类的成员也总是返回null——这种行为只出现在(IE的)顶层窗口中。
下面，让我们尝试相同的代码在没有兼容性标签的情况下会怎样。这时，该对象就能了解它所在的位置了，并且其行为类似于iframe。
3，在IE上进行测试
本质上，该对象在较旧的文档模式中被渲染为一个独立的实体，但在一个较新的文档模式中将被渲染为一个iframe。无论如何，在内部它们都是WebBrowser控件，所以Trident引擎会暴露相同的成员。
让我们重新回到较旧的documentMode，寻找一种利用这个混淆漏洞的方法，不过事情貌似并不那么糟糕，因为跨域限制仍然存在，而且X-FRAME-OPTIONS头部的工作效果非常好。 有一些成员，如window.name，它们是通过对象继承得到的(该对象会继承其父对象的名称)，不过这也不是太糟糕——但是某些广告技术会全地使用window.name来跨iframe传递信息，这种做法是很危险的。
话虽如此，至少有一个继承的对象真的会引起麻烦：位置。在对象标签内，location.href将返回主(顶层)窗口的位置。下面的代码将其对象的源指向object_location.html，但是当我们检索它的位置时，它返回的是顶层窗口。
