Update: I’ve posted a real world example of this bug being exploited.
This one has the same behavior on IE6, IE7 and IE8 betas.
I have only tested this with Flash swf files, but it’s likely that this security is applied and broken the same way, when navigating to different types of files.
When loading Flash file (swf) directly inside the browser without an html page container, for ex: http://example.com/game.swf , most browsers create an html page automatically and embed the swf inside it. FireFox and Google Chrome, for that matter, automatically create an embed tag with some default values, and IE uses this mshtml script (res://mshtml.dll/objectembed_neutral.js) to load the object.
The fact that this automatically created embed tag doesn’t mention the allowscriptaccess property it’s defaulted to samedomain. This way the swf file can script the automatically generated html page it resides in, using ExternalInterface, leading to a major security flaw. I will post about a real world example of this security flaw, shortly.
Internet Explorer, rightfully, consider this generated page as less secure and as such restrict access to the JavaScript document object. It’s preventing from the embedded swf to script the DOM of the page.
Just test it, go to any swf file on the web using Internet explorer, then run this script in the address bar javascript:alert(document); you’ll see the error “Access is denied”. Touching the document is prohibited!
But, all that is needed to compromise this security feature in IE is to reload the page. That’s it, just reload the page once by pressing F5. Run the script again javascript:alert(document); you’ll see the precious document and no error will be thrown.
Since most of the other javascript objects are still available and among these is the window native object. A swf file, for example, can reload the page on its own using window.location.reload() and then will be able to bypass the restriction and freely manipulate the page.
This script can run from inside the swf using ExternaInterface.call(“eval”, “script”); If the “try” clause fail it’s probably an IE browser and the page will reload immediately without the user noticing. The 2nd time the page loads the “try” clause won’t fail.
try{ $d = document; //Mess with the DOM }catch(ex){ window.location.reload(); }
I was impressed that Microsoft implemented such a security feature as opposed to FireFox, Chrome and others who don’t have a similar restriction. but, it needs to be done right otherwise it misses the point.
As I said, I’ll post a real world example of this being exploited, soon.