Hi Guya,
Maybe I missed something about your blog entry, but the IE stuff and the
other flash issues/features has been already covered here:
http://www.owasp.org/images/d/d8/OWASP-WASCAppSec2007SanJose_FindingVulnsinFlashApps.ppt
and here
http://www.owasp.org/images/8/8c/OWASPAppSec2007Milan_TestingFlashApplications.ppt
and SWFIntruder (https://www.owasp.org/index.php/Category:SWFIntruder)
also uses the try{}catch(){} block in order to bypass the security check
deployed on IE.
Regards,
Stefano
Il giorno lun, 15/09/2008 alle 12.04 +0300, Guy Aharonovsky ha scritto:
> Taken from my blog:
>>http://blog.guya.net/2008/09/10/bug-in-internet-explorer-security-model-when-embedding-flash/>> 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!
>> Error_Access_Denied
>> 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.
>> JavaScript:
>> 1. try{
> 2. $d = document;
> 3. //Mess with the DOM
> 4. }catch(ex){
> 5. window.location.reload();
> 6. }
>> 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.
----------------------------------------------------------------------------
Join us on IRC: irc.freenode.net #webappsec
Have a question? Search The Web Security Mailing List Archives:
http://www.webappsec.org/lists/websecurity/archive/
Subscribe via RSS:
http://www.webappsec.org/rss/websecurity.rss [RSS Feed]
Join WASC on LinkedIn
http://www.linkedin.com/e/gis/83336/4B20E4374DBA