Today, I was tasked with fixing a CMS integration that works in IE, but not . This integration was written in IE and only recently had our customers decided they wanted Firefox support, so understandably there were some cross-browser issues.

There is some normal stuff I don’t mind, such as not including both “name” and “id” attributes, as well as the IE-specific CSS and DOM functions that were used. Those are a pain to fix but normal when something this complex has been developed by somebody who only knows IE. No big deal. It’s the completely dumbfounding problems that I hate. Both of the following work in IE without any of these workarounds (although luckily also work with them in place, so I don’t have to duplicate code).
 

The first issue is more of a bug in my eyes. If you have an <iframe> with no source URL in your page, FireFox doesn’t initialise it with the baseurl etc of the surrounding window. This means that when I set the source of that <iframe> to something like <img src=”/someurl.gif”>, it breaks because there is no base to resolve the image to. I have to include an empty HTML file with the integration, load THAT as the default iframe URL and then it works.

 
The second issue is just pure madness. If a popup window is opened with JavaScript, and then the new window loads a different page (in this case a multi-level dialog, where hitting “ok” reloads the window with a new page), the second page cannot call functions on the parent window. The “window.opener” object exists, but none of the functions in the parent page are defined so it’s probably not even a reference to the correct window. This was no doubt done in the name of security, but my workaround demonstrates just how bloody insecure this “secure” browser is.

I created a wrapper page that contains a single <iframe> tag with the source set to the page I actually want to load. This is completely seamless to the user. Once the second page wants to call back to the opener window, it calls window.parent.function instead – this activates a function in the wrapper to call back to the actual window.opener.function (which it has access to since it hasn’t reloaded anything). Again, seamless to the user and if I do say so pretty damn clever šŸ˜‰

The problem is that this works even if the page inside the <iframe> is from a different domain. I discovered this when my test page (loaded off my hard drive with the iframe source set to my web server) worked in FireFox but not in IE (where it has security checks for clever little hacks).

This, my friends, is known as a cross-site scripting vulnerability. My wrapper page could load any website and then have full control over it. Like changing the form so it submits the password details to one of my sites instead of the real one. Admittedly this wouldn’t be seamless for HTTPS pages such as a bank website, but the number of times I’ve seen a user ignore a browser warning dialog makes that a moot point.

The funniest part? If you right click and view source, you get the source of the iframe and not the wrapper, so you’d have to be pretty cluey to work out what was going on.

 
So all of this shit (which isn’t necessary in IE) is worse than pointless, it’s giving everybody the false impression that FireFox is secure and website developers a headache in the process.

It’s no secret to anyone in the tech world that security in FireFox is not actually flawless, just that not enough people use it for virus writers to try and poke holes. I’d never actually seen proof of that until today though, and it makes me glad I use Opera. It’s supported by an actual company with their arse on the line, not a group of open source nerds.

Advertisements