This one surprised me quite a bit. A createPopup window that has been shown can outlive the browser itself. If the user closes IE while a modal-style alert from the popup is still open, the popup and...

This UXSS relied on an interesting property of createPopup: if the popup is shown (even at size 0×0) and its eval is called via setTimeout inside an iFrame, the popup stays alive across navigation....

This was a UI spoofing issue with IE's popup-blocked InfoBar. When a popup is blocked, the InfoBar shows the URL that was blocked. By using Navigate2 through an iFrame acting as a WebBrowser control,...

I was looking at the external object's less-travelled methods and found that NavigateAndFind with a non-empty third argument opens a new window pointing at any file:// URL — without any popup blocker...

This one involved a combination of a functionality regression in IE9 and a security bug. When the previous page in a tab was rendered in document mode 8 or lower, certain cross-frame operations that...

This was a concise one. Calling parent.document.open() from inside an iFrame and then immediately executing any JavaScript instruction caused the browser to crash. The instruction after the...

This was a behavioral quirk that Patrick Mann asked me to look into. When an iFrame's location is changed via window[0].location.replace() and the page is then refreshed, IE correctly honours the...

This crash required a race condition: open a new window, have it close itself immediately via a script, and then try to call a method on the returned window reference before the engine has finished...

I found this while experimenting with self-referential DOM mutations. If an iFrame uses execScript to call innerHTML on its own containing element in the parent, it destroys itself mid-execution,...

This one took me by surprise. Rapidly alternating an iFrame between an RSS/Atom feed URL and a regular HTML page caused an exploitable crash after just a few iterations. The key insight was combining...

I was exploring what setCapture could do across tab boundaries and found that it was surprisingly permissive. A page in one tab can capture all mouse clicks — even those made in a completely...

After playing around for a while with timing-based crash patterns, I found that calling document.open() on the main window while a dialog was freezing it produced an exploitable DEP violation. The...

This one surprised me. It turns out that alerts thrown inside an onunload handler are displayed in whatever tab gains focus after the originating tab closes — so the dialog appears to come from an...

This was a fairly simple crash to stumble onto. Calling document.open() on a freshly created Trident instance — either a new blank window or an htmlFile ActiveXObject — would reliably take the...

I was lucky to find this one early in my IE9 research. The idea is straightforward: open a new window that will redirect to a target domain, and simultaneously schedule a setTimeout against that...

After playing around with cross-frame script execution in IE9, I noticed that calling eval from inside an iFrame and then executing any document method on the parent would reliably crash the browser....

Another entry in the deadcall collection. Creating a DocumentFragment from an IFrame, reloading the IFrame (destroying the fragment's backing context), and then calling...

This was the first entry in what I called the "deadcall" collection — a series of crashes where Function.call (and equivalently bind and apply) was used to execute a method of one object on behalf of...

A deadcall crash using DOM Range objects: creating a range from an IFrame, reloading the IFrame, and then calling cloneRange() from a live range on behalf of the dead one caused a crash in...

A deadcall crash involving selection ranges: obtaining a range from an IFrame's selection, reloading the IFrame to destroy the range's context, and calling toString() from a live range on behalf of...

A non-crashing deadcall: caching the location object of an IFrame via valueOf(), letting the user navigate wherever they wished, and then calling location.toString.call(cachedLocation) revealed the...

IE8 blocked prompt() and VBScript's InputBox when called without user interaction, similar to the window.open() popup blocker. IE9 did not apply those restrictions, allowing a page to open...

By overriding Location.prototype.replace on the top-level window, an attacker page could intercept any call to location.replace() made by a framed page — including the common frame-breaking pattern...

Opening a blank window and then navigating it to a real URL caused a crash in the VMware SVGA 3D driver (vm3dum.dll) when IE9 was running inside a VMware virtual machine. The IE WebGraphics team...

This was an incomplete attempt at a drag-and-drop UXSS technique. The idea was to trick a user into dragging selected text from a cross-origin IFrame into an attacker-controlled drop target, leaking...

Enumerating the properties of a reference to an HTML Object element that hosted non-HTML content (XAML, XPS, PDF, etc.) via a for...in loop caused a crash in IE9's JScript9 engine. The crash occurred...

Gareth Heyes discovered that comparing the screenTop property before and after triggering a potential XSS could reveal whether the IE XSS filter had activated and shown its yellow InfoBar. When the...

Deliberately causing an error inside a cross-origin IFrame and catching the exception gave access to the exception object's constructor chain, which led to the Function constructor of the IFrame's...

Properties set on an IFrame's window object during its onunload event persisted after the IFrame navigated to a different origin. Setting onload in onunload was particularly convenient because the...

Combining the IFrame resurrection technique with a createPopup() that attached a keypress event handler made it possible to capture all keystrokes typed anywhere in the browser, even after the...

Calling location.replace() with a javascript: URL on a cross-origin IFrame executed the script in the IFrame's security context. The replace method did not apply the same javascript: protocol block...

The IE9 InfoBar (the yellow notification bar at the top of the content area) could be overlaid by a createPopup() positioned to cover it exactly. This allowed an attacker page to hide security...

When an IFrame loaded an XML feed or other non-HTML content, accessing its document from an inline event handler bypassed the same-origin check that protected it from script in regular functions....

Calling document.open() on a freshly created popup document caused a PROBABLY_EXPLOITABLE crash in IE9. The popup document was not in a state that supported being re-opened, and the open() call...

The location object in IE9 could be called as a function. When called this way with a javascript: URL, it executed the script in the IFrame's context, bypassing the normal javascript: protocol...

Another variant of the cached-collection UXSS family: document.childNodes from a same-origin IFrame remained live after a cross-origin redirect, and its nodes' ownerDocument pointed into the new...

By defining a setter on window.location using Object.defineProperty, an attacker page could intercept the moment a framed page tried to break out of its frame (a common frame-breaking pattern). At...

When an IFrame loaded non-HTML content (such as a .mht MHTML file), accessing its document property was normally blocked. However, doing so from an inline event handler on a button — rather than from...

Caching the location object of a same-origin IFrame, redirecting it cross-origin, and then calling .replace.constructor() on the cached location object gave access to the Function constructor of the...

Two related techniques for reading cross-origin document content in IE9. The first overrode a method on a cross-origin IFrame's window before the victim page called it; the second obtained a live...

By intercepting a property access that IE's own internal code triggered during a document.execCommand call, and using arguments.callee.caller.constructor to obtain the native Function constructor, it...

Focusing a cross-origin IFrame and then calling document.execCommand from the parent page allowed injecting arbitrary HTML attributes into the IFrame's content via the InsertImage command. The...

Caching a reference to document.getElementById from an IFrame, reloading the IFrame, and then calling .constructor() on the cached method caused a PROBABLY_EXPLOITABLE crash. The method reference...

Accessing window[0].self on a cross-origin IFrame returned a window reference that bypassed same-origin checks, allowing the attacker page to read the IFrame's document URL and body content directly.

The IE9 XSS filter used the HTTP Referer header to determine whether a reflected script came from the same page, and only blocked scripts that appeared to have been injected from outside. By...

Writing a <script language="xml"> tag into an IFrame's document caused IE9 to crash with a PROBABLY_EXPLOITABLE rating. The XML script language type was an obscure IE-specific feature, and its...

Parsing an SVG document via DOMParser and then accessing the viewport property on the root SVG element caused a crash in IE9. The DOMParser-created document was not a fully initialized rendering...

Repeatedly calling document.write(1) on a freshly created popup via setInterval caused IE9 to crash. The first call worked; the interval kept creating new popups and writing to them, eventually...

Calling dialogArguments.window in a tight loop from within a modeless dialog caused IE9 to crash with a PROBABLY_EXPLOITABLE rating. The dialogArguments object exposed the opener window, and repeated...

An <audio> tag with the autoplay attribute inserted via insertAdjacentHTML continued playing audio even after the page navigated away. The audio element was not torn down with the rest of the...