« Periodic Blurbs | Main | Cross Environment Hopping »

June 17, 2008

TrackBack

TrackBack URL for this entry:
http://www.typepad.com/services/trackback/6a00d835130c5153ef00e553760eb38834

Listed below are links to weblogs that reference JavaScript Code Flow Manipulation, and a real world example advisory - Adobe Flex 3 Dom-Based XSS:

Comments

Ory Segal

Hi,

Here are a few interesting remarks, which we did not include in the post:

1) The JavaScript code flow manipulation presented in the post, will not work in Firefox 2.0 (haven't tested this on other versions). The problem is that Firefox doesn't allow the child IFrame to set the propery _ie_firstload of the parent to any value. This is of course a secure (proper) behavior on Firefox's account.

2) There is another JavaScript code flow manipulation opportunity here, which is very amusing. Instead of diverting the JavaScript code into the ELSE block (the attack that was described in the blog post), we can let it flow into the IF block (by not creating a child IFrame called "_ie_firstload"). At this point, the JavaScript interpreter will run the line:

parent.BrowserHistory.setBrowserURL(url);

In order to manipulate this code flow, we can do the following:

a) Create a child IFrame at the (malicious) parent level, which is called "BrowserHistory", and which source points to another malicious page that we control on www.evil.site.

b) Create some page on the malicious web site, which contains yet another IFrame, called "setBrowserURL".

It appears that IE will be tricked the same way. This time, it is tricked to think that parent.BrowserHistory.setBrowserURL is a method, while in reality, it is an IFrame inside an IFrame.

(BTW - you would expect that IE will enforce the Same Domain Policy, since when you look at this from a JavaScript perspective, you are basically trying to access a JavaScript method, which should be limited to the same domain. If that was the case, we could've set the SRC attribute of the second IFrame to 'www.vuln.site' -- but hey, IE made life easier for us)

We wanted to use this technique in order to succeed in exploiting this DOM-based XSS on Firefox (by avoiding the problem mentioned in #1 above), but alas , Firefox throws an exception, saying that it does not have permissions to get the property parent._ie_firstload.

So to sum things up - in Firefox, if the IFrame exists, you can't trick FF to set a value to it (it doesn't get tricked by the "I'm an IFrame, but you can call me 'JavaScript Object'"), and if the IFrame doesn't exist, the it doesn't matter, since you can't even access the value in the IF condition.

Prasad Shenoy

Ory,
Kudos! A small correction however, the exploit URL that you have provided early on in the article (not the HTML snippet) won't work with the exploit (http://www.some.site/flex_html_wrapper.html#alert(document.cookie)) because of the missing "?".

This is a typo....

Ory Segal

@Prased - you are right. Thanks for pointing that out.

coco

Kudos! A small correction however, the exploit URL that you have provided early on in the article (not the HTML snippet) won't work with the exploit (http://www.some.site/flex_html_wrapper.html#alert(document.cookie)) because of the missing "?". glamour tea

Verify your Comment

Previewing your Comment

This is only a preview. Your comment has not yet been posted.

Working...
Your comment could not be posted. Error type:
Your comment has been posted. Post another comment

The letters and numbers you entered did not match the image. Please try again.

As a final step before posting your comment, enter the letters and numbers you see in the image below. This prevents automated programs from posting comments.

Having trouble reading this image? View an alternate.

Working...

Post a comment

Follow us on Twitter

AppScan Free Trial


Try IBM Security AppScan software at no charge.

Become a Fan