Security In IE7 & IE8

Posted by c4pr1c3 on March 18, 2008

I had some fun today on Internet Explorer and tested the new IE8 also.

Along, I also compared the new security features to IE7. And there are many

things to say about both versions. Don’t get me started on the usability. To

be honest it looks horrible. Don’t know if you ever noticed it, but

selecting text with your mouse has become a real challenge. It has some

strange selection boundary which results in selecting text you don’t want to

select. Typically Microsoft, onto the security features. You might have

heard or read about a new feature called XDR that allows cross-domain

requests. If not, I’ll explain it here in short detail as well as the other

new features before I’m going into reverse engineering IE7 & IE8.

The XDR object.

xdr = new XDomainRequest();‘POST’, ‘’);


Now, Mr.Bigglesworth needs to approve the send XDomainRequest header, but we

can approve the call by returning this header to the server that requested



Great, XSS made easy. No need for hijacked iframes, css or images. Nope pure

Javascript does the trick for us. This obviously can bypass many XSS filters

in use today, so if you run one be sure to check this beast out. In my

opinion this will broaden the attack landscape since there are more ways of

launching XSS or spreading worms. The XDR object also returns the

responseText that gives access to:






Useful, if you’re into worms and all.

next, I saw that they implemented cross-document messaging in the form of

the object postMessage. Opera already has it, and from a security standpoint

I don’t trust it. It basically means that a webpage can write into another

page that is running in the same session and on the same host by attaching

an event listener. Spoofing comes to mind, and maybe other attacks as well.

The real question is of course: what is it for? I don’t know.

Implementing it is a breeze:

page 1:

var doc = document.getElementsByTagName(‘iframe’)[0];

doc.contentWindow.postMessage(‘Hello Mr. Bigglesworth!’);

page 2:

document.attachEvent(‘onmessage’,function(e) {

if (e.domain == ‘’) {

if ( == ‘Hello Mr. Bigglesworth!’) {

e.source.postMessage(‘Meow! Meow! Dr. Evil!’);

} else {





Hash write access.

Another thing that caught my eye was write access to the hash of an url.

Doesn’t sound smart because I don’t want Javascript to manipulate the hash.

Not only can it be annoying, it can lead to security issues depending on the

setting of your website.


If I understand it correctly this feature allows users to favorite the slice

or put it in their feed reader. Better expect some buffer overflows here

since IE8 now listens for a tag called ‘hslice’ on any page it opens, would

be nice to fuzz this feature.

<div class=”hslice” id=”main”>

<h2 class=”entry-title”>All I want are friggin’ sharks with friggin’ lazer

beams attached to their heads! </h2>


GlobalStorage & SessionStorage.

IE8 jumped on the Mozilla bandwagon and implemented the Session object. I

can’t say I’m that impressed because I as I said before; allowing 10MB of

data to be stored in such object (XML file in IE8) isn’t smart. Let alone

the permanent storage of user tracking details, XSS worms and other


IE8 GlobalStorage

Reverse Engineering IE7 & IE8.

Okay, this is fun. I’m going to show you a couple things I found out about

Internet Explorer. First off IE8 prevents header forwards on files, pity

this was pretty ‘evil’ in MSIE 7 where it is still possible to change the

location of a file to a local file stored on your computer. It’s very


And IE7 follows it, whereas IE8 refuses to follow.

The reason why this is dangerous is because of this XML file that contains

system information which we could parse. Useful for reconnaissance and

possibly other attack schemes.

Results in IE7:

– <!– Copyright (c) Microsoft Corporation


– <assembly xmlns=”urn:schemas-microsoft-com:asm.v1″

xmlns:asmv3=”urn:schemas-microsoft-com:asm.v3″ manifestVersion=”1.0″>




type=”win32″ />

Windows IE




publicKeyToken=”6595b64144ccf1df” language=”*”




– <trustInfo xmlns=”urn:schemas-microsoft-com:asm.v3″>

<requestedExecutionLevel level=”asInvoker” uiAccess=”false” />




– <asmv3:windowsSettings






If you notice correctly I read res://ieframe.dll/24/123 located on

ieframe.dll which is the IEDataObjectWrapper (InProcServer32) I don’t know

why they still allow this to be browsable, because you can resource it on

iframes, XML and as a Javascript source. So I went further to find all data

object in IE8 and a few in IE7.

IE7/8 data sources are:










**res://ieframe.dll/Version Info/1




























**res://ieframe.dll/preview.dlg (dialog)




res://ieframe.dll/24/123 (XML file)

IE6 has a few too:








As well as others.

These are nice to play with some more, I haven’t digged any deeper yet but

this is quite nice to have a look at. So, enough building blocks to pentest

IE a little further. If you find anything notable, do let me know.