That's the central question being discussed by security professionals following the cancellation of a presentation on user-interface overlays -- or "clickjacking" as some have dubbed the threat -- at last week's Open Web Application Security Project (OWASP) AppSec conference in New York City.

On Friday, the U.S. Computer Emergency Readiness Team (US-CERT) warned network administrators to beware of the technique.

"Clickjacking gives an attacker the ability to trick a user into clicking on something only barely or momentarily noticeable," the group stated. "Therefore, if a user clicks on a web page, they may actually be clicking on content from another page."

Two researchers, Robert Hansen and Jeremiah Grossman, planned at AppSec to discuss the threat of using Web graphics to persuade a victim to click where an attacker wants on a page. The technique, which is also known as well as user-interface (UI) redressing and IFRAME overlay, can be used by an attacker to hide a button or link on a legitimate page, such as a bank's account page or Web mail application, using other Web content to mask the page's context.

A Web user might think, for example, that they are clicking on a button to close a dialog box, when the button press in reality deletes all their e-mail messages in Gmail. Or, a user might believe they are clicking on a button to decline to take a survey, when they are actually transferring money from their bank. The technique could be used to raise an article's Digg score or get paid for a pay-for-click advertisement, said Grossman, the chief technology officer for Web security firm White Hat Security.

"The list is virtually endless and these are the more relatively harmless examples," he told SecurityFocus in an e-mail interview. "Next consider that an attack can invisibly hover these buttons below the users mouse, so that when the clicks on something the visually see, they actually are clicking on something the attacker wants them to. Now, what could the bad guy potentially do with that ability? The more we researched, the worse the exploits become."

Hansen and Grossman canceled their presentation after demonstrating to software maker Adobe that one of its products could be affected by the attack.

"While they saw this issue as primarily a web browser issue, they showed us that one of their demos included an Adobe product," David Lenoe, a program manager for Adobe's Product Security Incident Response Team (PSIRT), said in a blog post. "We worked together with Robert and Jeremiah to assess the impact of this issue, and they determined that it was in our customers’ best interest to refrain from making this issue public until Adobe and web browser vendors have a chance to provide a fix or fixes to our mutual customers."

While the issue is serious, a number of considerations could make a practical attack difficult. The attacker has to know where the button is on a page and, thus, the attack requires a staging to get right, said Hansen, an independent security consultant. In addition, the attacker must be able to access the Web page in the same way as the victim. Finally, with each additional click required by a Web page to complete an action, the attack become harder.

"If I was a bad guy and I just wanted to screw some people over, clickjacking would not be my attack of choice," Hansen said. "There are so much easier exploits out there -- in terms of the amount of staging you have to do ahead of time -- that an attacker could use."

That's good, because solving the clickjacking problem will not be easy. In an e-mail to a mailing list run by the Web Hypertext Application Technology (WHAT) working group, browser expert Michal Zalewski described five potential fixes that fall into two broad categories. Opt-in solutions would require each Web site to fix the issue, but -- while simpler -- many Web sites would fail to implement changes. Opt-out solutions would rely on modifying the behavior of IFRAMEs to make clickjacking attacks more difficult.

Using a browser plug-in to block Javascript, such as NoScript for the Firefox browser, can protect against the most serious forms of the attack, said Giorgio Maone, CEO of Italy-based InformAction, the maker of NoScript.

"JavaScript increases the effectiveness of this attacks hugely, because it ensures that user will click our target no matter where he points -- that is, we can move the target around to stay always under the mouse pointer," Maone said in an e-mail interview with SecurityFocus. "However, we can think of less effective (or) practical, but still feasible, scriptless scenarios."

However, Zalewski warned, blocking Javascript can also break a potential workaround for the issue that Web developers could deploy.

Currently, Microsoft and Mozilla are investigating the issue, according to statements sent to SecurityFocus.

"No one knows what the best solution will be or when it will come," WhiteHat's Grossman said. "(It) could possibly require an architectural change."

If you have tips or insights on this topic, please contact SecurityFocus.