Friday, June 29, 2012

KB2699988, iFrames, Anchor tags and the headaches that won't stop.

Recently, a page on one of our sites stopped working.

The page lists things and has anchor tags that will take you to the relavant part of the page. We are currently excusivly using IE8.

The trick about this page is that it is displayed on our sharepoint portal using a Page viewer webpart. The page is from a legacy app, and the easiest way to put it on the portal was using an iFrame.

The second notable piece of information is that the page viewer webpart is set with a heigh that is large enough to show the entire page inside the iframe without scrolling, something around 15000px. To the user, it looks as if the page is part of the portal.

Recently, the anchor tags at the top of the page in the iFrame stopped working. The page would no longer scroll down to show the relavant part of the iFrame'd page. Clicking the anchor tags would do nothing.

What's going on? These worked for 2 years without any problems!
After a lot of searching and testing, I found out that this was a potential security hole. The problem is that when the user clicks an anchor tag, the main page has to scroll down to show the part of the inner iframe(the page is like 15000px long).
Because the outer page scrolls, it's possible to setup an exploit that allows the outer page to tell if something exists on the inner page. Someone wrote about it at a blackhat conference: The explaination starts at page 38.

I found this because the same page does not work in Firefox or chrome. Fortunatly, Firefox is fairly open about their bugs and has a comments section to allow people to discuss the problem and the solution. The firfox bug ( talks about the problem. This was helpful to track this down as a security update and not something that we changed. They fixed it in early 2011.

 It looks like that this same problem was fixed in KB2699988. Reading through the hotfixes that are in KB2699988, nothing really jumps out at me that says that this was fixed or changed. The closest think I can find is "A memory leak may occur when a modal dialog box opens in an iframe in Internet Explorer 8 ". This to me doesn't have anything to do with the problem I'm running into, but if it does, then KB2695422 is the culprit.

Update: Here's a solution that should work - but only if you have access to change the iFrame page's code. -

 I haven't found a good solution to this yet. If you setup the iFrame so that the height is less than the page height, you will somewhat fix the problem. It will cause you to have scroll bars, and the iFrame will scroll. It won't cause the outer page to scroll though, so you're users won't be able to see it.

 The other solution I'm looking into is changing the code on the page inside the iFrame so that it uses JavaScript to scroll the page. Hopefully this will work for me, but for you, you may not be able change the code inside the iFrame.

 I will note that this isn't specifically a SharePoint problem. You can test this out by creating a page that has an iFrame in it. The iFrame height should be set long enough that it's taller than the page - something like 2000+ pixels.
(Replace the curly brackets with GT and LT's, obviously)
At the top of the iframe's page, put a link to an anchor Tag {a href="#end"} go to end {/a}. At the bottom of the iFrame'd page, put an anchr Tag like {a name="end"}end{/a} the End should be way down at the bottom of the page, and not visible(add some gangsta Lorum Ipsum, or just a bunch of {BR}'s to make the page really long,  but not so long that it is more than the 2000 pixels you set it to and introduces some scroll bars.

To the user, it would look like one long page with a link at the top and at the bottom. Clicking the 'go to end' link at the top of the page should scroll the page down to the bottom. It will if the page is not in an iFrame. If the page IS in an iframe, it won't work. Nothing happens.

I guess this just shows that Firefox and Chrome are more secure browers. They fixed this 'hole' (and I'm not sure I'm ready to agree that this is a legit security issue given the consequenses of disabling the 'feature') more than a year and a half before IE fixed it.