What is clickjacking?

Clickjacking is an attack that fools users into thinking they are clicking on one thing when they are actually clicking on another. Its other name, user interface (UI) redressing, better describes what is going on. Users think they are using a web page’s normal UI, but in fact there is a hidden UI in control; in other words, the UI has been redressed. When users click something they think is safe, the hidden UI performs a different action.

The attack is possible thanks to HTML frames (iframes), the ability to display web pages within other web pages through frames. If a web page allows itself to be displayed within a frame, an attacker can cover the original web page with a hidden, transparent layer with its own JavaScript and UI elements. The attacker then tricks users into visiting the malicious page, which looks just like a site users know and trust. There is no indication there is a hidden UI layered over the original site. Users click a link or a button, expecting a particular action from the original site, and the attacker’s script runs instead. But the attacker’s script can also execute the expected action to make it appear nothing has gone wrong.

Clickjacking itself is not the end goal of the attack; it is simply a means of launching some other attack by making users think they are doing something safe. The actual attack can be virtually anything possible via web pages. This ranges from malicious actions, such as installing malware or stealing credentials, to more innocuous things, such as boosting click stats on unrelated sites, boosting ad revenues on sites, gaining likes on Facebook, or increasing views of YouTube videos.

Are there any defenses against clickjacking?

There are no perfect defenses against clickjacking. But there are actions you can take to reduce your risk. On the client side, disabling JavaScript is effective, but since so many sites rely on JavaScript, turning it off renders many sites unusable. There are some commercial products that can provide protection while trying not to affect the real use of iframes. This can work well within an organization, where the products can be rolled out to employee desktops, but it does nothing to protect customers using the organization’s websites.

What are X-Frame-Options?

Another option is to use the X-Frame-Options HTTP header. It allows an application to specify whether frame use is simply denied, via the DENY value, or the use of frames is allowed, by the SAMEORIGIN or ALLOW-FROM values. Mainstream modern browsers do support this header option, but other browsers may not.

Possible X-Frame-Options:

X-Frame-Options: DENY
X-Frame-Options: SAMEORIGIN
X-Frame-Options: ALLOW-FROM

What is Content Security Policy (CSP)?

The final and more modern option is to use Content Security Policy (CSP) and its frame-ancestors directive. This directive allows the application developer to disallow all frame use or specify where it is allowed, similar to X-Frame-Options. CSP is not available in all browsers, and browser plugins and add-ons may be able to bypass the policy. If both the X-Frame-Options header and CSP frame-ancestors are used, browsers are supposed to prefer CSP’s directives, but not all will.

Possible CSP frame-ancestor settings:

Content-Security-Policy: frame-ancestors 'none'
Content-Security-Policy: frame-ancestors 'self'
Content-Security-Policy: frame-ancestors

Because none of these defenses are perfect, defense-in-depth is a good practice, and there is nothing wrong with using all three defenses on your websites.