Adobe works to pre-empt a 'clickjacking' security nightmare

Cross-site scripting vulnerabilities remain the most difficult for Web browser and tool manufacturers to thwart, especially because legitimate sites may be hosted by multiple domains. Today, Adobe Flash finds itself in the crosshairs.

A relatively ancient technique for hijacking a Web page's hyperlinks by overlapping them with different, invisible hyperlinks that lead the user someplace else, has reared its ugly head again, but this time outside the realm of HTML: Recently revealed proofs-of-concept show that invisible Flash elements can maliciously lead users to mock Web pages; and now it's been revealed that Adobe was already working with security engineers to fix the problem before the latest proof-of-concept was leaked.

An Adobe security advisory published yesterday alerts users to an exploit now being called clickjacking, and credits five security engineers with helping Adobe to resolve the issue. Two of those engineers, White Hat Security's Jeremiah Grossman and Robert Hansen, had planned to demonstrate the Flash flaw themselves at a security conference in New York, but were asked by Adobe to suspend their speech, and they complied.

What Grossman and Hansen would have demonstrated was actually an ancient problem has plagued Web security developers in one form or another for this entire decade.

Years ago, in the effort to make Web page elements more dynamic, developers created ways to give floating frames such as <IFRAME> elements transparent backgrounds. Well, if the text inside such a frame were also transparent, a malicious hyperlink could be rendered completely invisible, and then repositioned anywhere on a Web page -- including on top of some other page's perfectly visible, legitimate hyperlink.

When Microsoft first made this kind of transparency available in Internet Explorer 5.5 in late 2000, it did not foresee the security ramifications; only later did it realize that an <IFRAME> element hosted by another domain, placed atop someone else's page, could be detrimental.

The up-and-coming Firefox browser effort, meanwhile, was joined by individuals who at least acknowledged the problem, even if action on the matter came much later. In June 2002, contributor Jesse Ruderman wrote for Mozilla's bug tracking size Bugzilla, "I find it strange that iframe transparency was designed in a way that is both less intuitive and less secure than requiring the iframe content to declare its background as transparent. I would like this bug to be fixed before Web sites begin to rely on this method. It would really suck if we decide later that it is a security hole and are not able to fix the browser without breaking existing sites."

Fast-forward to yesterday morning, two weeks after Hansen and Grossman delayed their speech in New York. A proof-of-concept video emerged showing how the entire concept could be turned on its ear: A Flash page purporting to be a "Catch the Button" game, enticing the user to click on a moving target, can actually be an opaque element whose clicks are transparently diverted to a legitimate element underneath. Thus the user could be blithely clicking on a moving target, racking up big points in the process, while at the same time actually operating the Flash Security page that enables access to the user's Web camera.

Once the word was already on the street, Hansen was permitted by Adobe to speak about his take on the flaw. "Thankfully, Adobe has been working on this since we let them know, so despite the careless disclosure, much of the work to mitigate this on their end is already complete," Hansen wrote for his ha.ckers.org blog yesterday.

He went on to list twelve separate scenarios where clickjacking can be employed, only a few of which actually involve Adobe Flash. Five of those scenarios, he said, have either been fixed or are being fixed by Adobe for a future security release; and another scenario has been addressed and fixed by Mozilla for Firefox, he added.

Two weeks ago -- perhaps as a coincidence of timing -- Google security engineer Michal Zalewski authored a post for the W3C's WHAT Working Group, alerting them to the danger that still exists with regard to the <IFRAME> element and clickjacking, and suggesting that perhaps standards themselves should be amended to enable site developers to thwart the problem through better design. "We feel that current Web browser designs provide no adequate tools for Web site owners to protect their applications against such attacks," he wrote.

Some of Zalewski's suggestions included making it possible for JavaScript to detect when an element has been engaged out of context -- for instance, by an outside domain -- so that it can respond differently than it would by default. Another involves creating a new HTTP mechanism for signifying up front, during the connection phase, when a Web page does not want to be scriptable across domains. "All these could be tweaked, combined, etc.," Zalewski wrote, "[but] none of them seems quite ideal."

Hansen pointed out that a clickjacking attempt can only be successful if the malicious page accurately reflects the layout of the legitimate one. So a developer may be able to thwart such an attack with what he calls "frame-busting code."

"Frame busting code is the best defense if you run Web servers, if it works (and in our tests it doesn't always work)," Hansen wrote yesterday. "I should note some people have mentioned security=restricted as a way to break frame busting code, and that is true, although it also fails to send cookies, which might break any significant attacks against most sites that check credentials."