Clickjacking

What is clickjacking?

In a clickjacking attack, the user is tricked into interacting with a user interface element that they do not see. The attacker designs a malicious page with fake visual elements. The user is then lured into clicking on these elements and unknowingly clicks on an obscured interactive component that often comes from an embedded page.

The term clickjacking comes from the words click and hijacking, and it was first used by security researchers Jeremiah Grossman and Robert Hansen in their research on an Adobe Flash vulnerability. The wider technical term for similar attacks is user interface redress (UI redress attack). There are other terms related to clickjacking, such as likejacking (hijacking Facebook page likes), cursorjacking, filejacking, and more.

Clickjacking is an attack aimed both at a user and a website or web application. The target user is the direct victim, and the target website or application is used to provide a tool page. Such attacks have been possible since 2002 but are only treated as a web application security issue since 2008.

Clickjacking attack examples

There are many clickjacking techniques, but most of them use HTML iframes as the primary mechanism. Here are some of them:

• The attacker creates an invisible iframe (transparent overlay) over the malicious page and loads the tool page into that overlay. The malicious page contains a visual element that lures the user into clicking by pretending to offer attractive functionality. For example, it may be a graphic element that looks like a video player with a play button in the middle. When the user clicks on the play symbol, due to the overlay, they are actually clicking on a UI element on the tool page, such as a Facebook “like” button.
• The attacker creates a 1×1 pixel iframe that moves with the mouse cursor thanks to clever manipulation of div elements, JavaScript, and CSS stylesheets. Due to its size and positioning, this frame is completely invisible (hidden under the cursor symbol tip). No matter where on the page the user clicks, they click on whatever is loaded and positioned in this 1×1 frame.
• The attacker uses fragments of the tool page on the malicious page by cropping. For example, they can create an iframe that contains only the real Submit button from the tool page and arrange it among the elements of a malicious page.

You can find a full list of clickjacking techniques on the W3C (World Wide Web Consortium) security page.

Potential consequences of a clickjacking attack

Attackers may abuse clickjacking vulnerabilities to achieve many different goals:

• Gain followers on social media and then, possibly, sell the social media account/page for mass marketing
• Gain email or RSS subscribers for the same purpose as with social media followers
• Use the fact that a user is logged into their e-commerce account and exploit active authentication to have them buy products on behalf of the attacker
• Have the user unknowingly transfer funds to the attacker
• Have the user download malware (e.g., a trojan)
• Hijack API tokens

In general, the potential scope of clickjacking depends only on the attacker’s imagination and their ability to find a vulnerable tool page to use for the attacks.

How to detect clickjacking?

The only way to detect if one of your pages is being used as a tool page for a clickjacking attack is to analyze the server-side logs for suspicious patterns. It’s much better to prevent clickjacking attacks by detecting vulnerabilities and misconfigurations that make it possible to use your page as a tool in a clickjacking attack.

• If you only use commercial or open-source software and do not develop software of your own, it may be enough to identify the exact version of the system, application, or add-on you are using. If the identified version is susceptible to clickjacking, you can assume that your software is vulnerable. You can identify the version manually or use a suitable security tool, such as a software composition analysis (SCA) solution for web applications or a network scanner for networked systems and applications.
• If you develop your own software or want the ability to potentially find previously unknown clickjacking vulnerabilities (zero-days) in known applications, you need to perform manual penetration testing with the help of security researchers or use a vulnerability scanner tool that supports clickjacking vulnerability detection. Examples of such tools are Invicti and Acunetix by Invicti, which are both able to detect missing or misconfigured Content-Security-Policy and X-Frame-Options HTTP headers discussed below. We recommend using this method even for known vulnerabilities.

How to prevent clickjacking attacks?

Everyone responsible for web security must make sure that their company’s web assets cannot be used in a clickjacking attack. Your best bet is to prevent potentially malicious sites from including your content in iframes.

There are several mechanisms for clickjacking defense, and you can combine several of them to ensure full coverage. Below you can see these techniques in order of preference, but note that while they will prevent most clickjacking attacks, there is always the risk that highly skilled attackers will come up with more innovative methods.

Method #1: Content-Security-Policy: frame-ancestors

Content-Security-Policy (CSP) is an HTTP response header. It was designed primarily to protect against cross-site scripting (XSS) attacks. Currently, it also includes an anti-clickjacking frame-ancestors directive. This directive controls how the page can be embedded by different sites by specifying parent pages that may embed the page. Embedding control covers the following tags: <frame>, <iframe>, <embed>, <object>, and <applet>.

How to use the CSP frame-ancestors directive

Content-Security-Policy can only be used directly as a response header and not in meta tags. The best option is to configure your web server to automatically include the directive with every page it serves. The frame-ancestors directive is just one of the many directives you can use.

Here is an example of a CSP frame-ancestors directive that allows a page to be embedded only in itself and in Invicti web pages:

Content-Security-Policy: frame-ancestors 'self' https://*.invicti.com;

For full information on other Content-Security-Policy directives, see the Mozilla developer article about CSP.

Advantages and disadvantages of the CSP frame-ancestors directive

The frame-ancestors directive is very versatile, with many options for whitelisting hosts and schemas. If you need to cover multiple use cases, you can simply include several CSP headers.

The downside is that several older web browsers do not support frame-ancestors, most notably with the complete lack of support in any version of Internet Explorer. Considering that this browser is still popular in some organizations, the frame-ancestors directive alone is not enough to protect all users. To cover these cases, it must be combined with other defenses, such as the X-Frame-Options header. Note that older versions of Firefox and Chrome go against the official CSP definition by ignoring the frame-ancestors directive if the X-Frame-Options header is present, while it should be the other way around.

To see the full browser compatibility chart for CSP frame-ancestors, visit the Mozilla developer page for the frame-ancestors directive.

Method #2: X-Frame-Options

X-Frame-Options (XFO) is an HTTP response header. It was introduced in 2008 in Microsoft Internet Explorer 8. However, it was never accepted as an official standard (despite the IETF publication RFC 7034 from 2013). This response header is a simple predecessor of the frame-ancestors directive. Formally, CSP frame-ancestors obsoletes the X-Frame-Options header.

How to use X-Frame-Options

X-Frame-Options can only be used directly as an HTTP header, and not in meta tags. As with CSP frame-ancestors, your best option is to configure your web server to automatically include the directive with every page.

You can only use the X-Frame-Options header once per page. If you specify it more than once, one header will override the other. Here is an example of an X-Frame-Options header that only permits a web page to be embedded by pages that begin with www.invicti.com (but not invicti.com on its own):

X-Frame-Options: allow-from https://www.invicti.com/ 

Advantages and disadvantages of X-Frame-Options

The X-Frame-Options HTTP header remains the most commonly supported clickjacking defense. It is currently supported by all major browsers but not in its entirety – Chrome, Safari, and Firefox do not support the allow-from directive, only the deny and sameorigin directives. Due to the popularity of these browsers, it is therefore recommended not to use the allow-from directive at all.

The X-Frame-Options header is very limited, which introduces difficulties for website designers. For example, users of the Jenkins CI solution cannot include Jenkins frames in other pages due to the X-Frame-Options policy.

To see the full browser compatibility chart for X-Frame-Options, visit the Mozilla developer page for the X-Frame-Options header.

Method #3: Framebusting

Framebusting (also known as framebreaking or framekilling) is a client-side technique. It does not require any modifications to HTTP headers – all you need to do is include a short script in your web page HTML code. It is the most generic protection against clickjacking and works even in legacy browsers (such as IE6). However, it is not as reliable as HTTP header options and, in some cases, may be circumvented (for example, in Internet Explorer 8 by loading the content into <iframe security=restricted>).

A good general framebuster script to use was published on Codemagi in 2010 and is still valid:

<style id="antiClickjack">body{display:none !important;}</style><script type="text/javascript">
if (self === top) {
  var antiClickjack = document.getElementById("antiClickjack");
  antiClickjack.parentNode.removeChild(antiClickjack);
} else {
  top.location = self.location;
}
</script>

Note: Do not use <script>if (top!=self) top.location.href=self.location.href</script> to protect your web page from clickjacking. This is a very old method that can be easily circumvented in a number of ways.

Frequently asked questions

Related blog posts

• What are clickjacking attacks
• Clickjacking attacks on Facebook
• Using Content Security Policy to secure web applications

Written by: Tomasz Andrzej Nidecki, reviewed by: Aleksei Tiurin