The technique, which is also known as user-interface (UI) redress 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. Using well-placed graphics, an attacker could persuade a victim to click where an attacker wants on a page.

While browser makers had known about the possibility of user-interface redress, or "clickjacking" as Hansen and Grossman call the technique, the two security researchers had found at least one major security implication: The attack also affected one of Adobe's products.

Hansen and Grossman chatted with SecurityFocus managing editor Robert Lemos to talk about clickjacking as well as possible solutions to the problem.

SecurityFocus: What is clickjacking? How does it work?

Grossman: Think of any button -- image, link, form, etc. -- on any website, internal or external, that you can get to appear between the Web browser walls. This includes wire transfer on banks, DSL router buttons, Digg buttons, CPC advertising banners, and Netflix queues.  Next consider that an attacker can invisibly hover these buttons below the user's mouse, so that when a user clicks on something they visually see, they're actually clicking on something the attacker wants them to.

Now, what could the bad guy do with that ability? The potential is limitless. The more we researched, the worse the exploits became. Several different flaws exposed themselves, making a once underestimated attack technique extremely scary.

Is this a problem that you and Robert discovered? Or has it been known before this? How did you come to focus on this issue?

Grossman: Robert and I discovered the clickjacking attack technique for ourselves around a year and a half ago. Recently we've been told that the Web browser vendors knew of the issue as early as 2002. What we also know is the attack has been largely underestimated and undefended by the Web security community in general. Post Black Hat 2008, some research we were conducting was furthered by using clickjacking.

Why discuss it now? Has anything changed in regards to the threat level of this?

Grossman: We felt the true power of clickjacking was not well known or fully investigated, so we planned to present it at the OWASP conference. What we didn't know -- didn't realize -- at the time was that one of our proof-of-concept demo examples used a zero-day in an Adobe product. This further verifies that clickjacking has many uses other than what people have given it credit for.

What are likely ways that an attacker could use clickjacking? Are these easy attacks?

Grossman: Other than the examples cited in question #1, attackers can also bypass token-based CSRF (cross site request forgery) protections. This on its own is a really big deal.

Is Javascript required to execute these attacks?

Grossman: Having JavaScript turned on in the Web browser makes clickjacking attacks easier to perform, but strictly speaking it's not always required for successful exploitation.

In a fairly comprehensive e-mail to the WHATWG, researcher Michal Zalewski talked about possible solutions to the clickjacking. What problems do you see in fixing this issue?

Hansen: The obvious issues are around usability of existing applications.  The more UI controls you put in place to limit clickjacking the more likely you are going to hurt existing applications that are benign.

Zalewski talked about this following into two categories: opt-in solutions and opt-out solutions. Can you describe the differences between the two routes?

Hansen: Opt-in solutions will get the same level of adoption as any other security would.  We still have tons of vulnerabilities to known problems on the Internet that are solved by simple patches.  In my mind, while they do solve the problem for a few cases, it really will not have a big enough impact to stop the threat in any meaningful way.

The opt-out solution he provided also doesn't have any real chance of success in any reasonable amount of time given that a huge chunk of the internet would need to be re-worked. The best solutions I've heard, if you can call them solutions, are browser-based and require no changes to the web-servers. That'll get the quickest adoption rate and is the most viable solution. Unfortunately, with any change there is a huge amount of regression testing, and you're likely to break a lot of the more complex web interfaces out there, that use some similar technologies by design.  They may not mean to hurt anyone, but their interfaces will no longer work the same way if the browsers make substantive changes.

If I am a bank or another Web site and I want to try and make sure that my visitors are not affected by clickjacking, is there anything I can do at this point?

Grossman: There are three things websites owner can do to help prevent clickjacking. 1) Add JavaScript frame-busting code to your entire website to ensure none of the Web pages can be framed in by a malicious third-party. 2) Important action buttons on the website, such as form submit buttons, should require JavaScript to execute which helps prevent certain browser feature that negate solution #1. 3) Sensitive actions should be validated using an out-of-band communication channel, which may include email or SMS.

As an Internet user, is there anything I can do to make sure that I am not attacked with clickjacking?

Grossman: There a few things that are helpful, but nothing is 100% effective. 1) Make sure you logout of websites when you are done conducting business. 2) Install NoScript for Firefox. 3) Disable all plugins.