Clickjacking refers to any attack where the user is tricked into unintentionally clicking an unexpected web page element. The name was coined from click hijacking, and the technique is most often applied to web pages by overlaying malicious content over a trusted page or by placing a transparent page on top of a visible one. When the user clicks an innocent-looking item on the visible page, they are actually clicking the corresponding location on the overlaid page and the click triggers a malicious action – anything from faking a like or follow on social media to siphoning money from the user’s bank account.

The majority of clickjacking attacks exploit vulnerabilities related to HTML iframes and protection methods center around preventing page framing. In this blog post, we will see how clickjacking works, how it can be prevented, and why this threat to application security is not going away any time soon.

Click Here to Begin: What a Typical Clickjacking Attack Looks Like

By far the most common approach to clickjacking involves presenting the user with a mix of two overlaid web pages in the browser window and some kind of incentive to click in specified places. The attacker starts by loading the vulnerable target website into an iframe, sets it to full transparency, and places the frame in front of a malicious web page created to elicit clicks in suitable places.For example, imagine a fun browser-based game displayed in a popup window, perhaps offering prizes or attractive content for winners. The game could be shown as the background page, and the targeted web application, such as a banking or e-commerce site, overlaid on top of it in a completely transparent frame. The attacker crafts the game page so that clickable items are in the same position as selected controls on the targeted site. When attempting to click in-game items, the user is actually clicking invisible controls on the vulnerable web page with potentially serious consequences.Depending on the site used, the victim might be unwittingly sending 5-star reviews, liking dubious Facebook pages, giving permissions to Facebook applications, logging in using SSO schemes, or using 1-click shopping to ship expensive items to the attacker. If combined with drag-and-drop techniques, the attack might also trick the user into completing text fields in a web form or filling CAPTCHAs. In this case, carefully prepared interactions with the game cause the user to unknowingly drag text on the invisible page and drop it on a form field.

Types of Clickjacking Attacks

Clickjacking is not one specific attack, but a broad family of attack vectors and techniques, broadly termed UI redress attacks. Attacks can be divided into two general categories, based on the use of overlaid content. Overlay-based attacks are by far the most popular, and embedding pages in invisible iframes is the most common technical approach here. Again, there are several main categories of overlay-based clickjacking:

• Complete transparent overlay: This is the method used in our example above, where a transparent legitimate page (here called a tool page) is overlaid over a carefully crafted malicious page. The tool page is loaded into an invisible iframe and positioned above the visible page by setting a higher z-index value. One of the first high-profile clickjacking attacks used this method against the Adobe Flash plug-in settings page to trick users into giving Flash animations access to the computer’s camera and microphone.
• Cropping: For this attack, the attacker overlays only selected controls from the transparent page on the visible page. Depending on the aim of the attack, this could mean covering buttons with invisible hyperlinks to trigger a different action than expected, covering text labels with misleading instructions, replacing button labels with false commands, or covering up the entire legitimate page with misleading content, leaving only one original button exposed.
• Hidden overlay: This was the first demonstrated approach to clickjacking. The attacker creates a 1x1 pixel iframe containing malicious content and positions it under the mouse cursor, so it’s hidden by the cursor but any click will register on the malicious page.
• Click event dropping: The legitimate page is displayed in the foreground, completely obscuring the malicious page behind it. The attacker sets the CSS pointer-events property of the top to none, causing click events to “drop” through the overlaid legitimate page, only registering on the malicious page below.
• Rapid content replacement: Opaque overlays are used to cover up the targeted controls, only removed for a fraction of a second to register the click, and immediately replaced. This requires the attacker to predict the exact moment of the victim’s click, but with a little knowledge of computer user habits and psychology, it’s easier than it sounds.

Even without exploiting clickjacking vulnerabilities to insert overlays, attackers have many options for tricking users into clicking unexpected controls:

• Scrolling: The attacker partially scrolls a legitimate dialog box or other web page element off the screen, so the user only sees some of the controls. For example, a warning dialog might be scrolled off the screen so that only the OK and Cancel buttons are visible, with the attacker positioning an innocuous prompt text so it looks like the buttons apply to this message, and not a warning.
• Repositioning: This attack requires the attacker to rapidly move a trusted dialog (or another UI element) under the cursor while the user is focused on clicking some other, innocent-looking items. If this works, the user will instinctively click the substituted control before they realize that something has changed. As with rapid content replacement, the attacker may quickly move the dialog back after the click to avoid detection.
• Drag-and-drop: While most clickjacking attacks explicitly focus on intercepting clicks, drag-and-drop vulnerabilities can be exploited to trick the user into performing a variety of other actions, such as completing web forms by dragging invisible text into invisible text boxes or revealing sensitive personal information to the attacker.
• ...and many others: The dynamic interactions between the user and web page elements made possible by combining JavaScript, DOM, and CSS offer innumerable options for tricking users into performing unexpected actions. Because clickjacking attacks exploit the user’s trust in the displayed content and controls, they can be hard to detect automatically, and new attacks will continue to appear.

How to Prevent Clickjacking

The majority of popular clickjacking attacks involve framing the targeted web page in an iframe at some stage, so all the main prevention methods aim to disallow framing. Legacy solutions used client-side scripts to break pages out of frames, while more modern and secure approaches rely on setting HTTP security headers to specify framing policy:

• Framebusting or framebreaking: Before support for new HTTP headers became widespread, website developers were on their own and had to deploy special framebuster (or framekiller) scripts to prevent their pages from being framed. The first framebusting scripts simply checked top.location to make sure this was the current page – if not, top.location was set to self. However, these scripts could easily be blocked from the outer frame or otherwise bypassed, and more elaborate solutions were developed. Even so, numerous ways of bypassing even the most elaborate framebreakers exist, and such scripts should only be used to provide rudimentary protection for legacy browsers. The approach currently recommended by OWASP is to hide the entire body of the HTML document and only show it after verifying that the page is not framed.
• X-Frame-Options: Probably the best solution at present is to use the X-Frame-Options (XFO) HTTP response header in server responses. Originally introduced by Microsoft in Internet Explorer 8 and later formalized in RFC 7034, the X-Frame-Options header is used to specify whether a page can be embedded in a <frame>, <iframe>, <embed> or <object> element. The header supports three possible directives: deny to block all framing attempts, sameorigin to allow framing only by pages of the same origin, or allow-from to allow framing by pages from specified URIs. However, allow-from is unsupported by several browsers (including Chrome and Safari), so if you need to specify sources, you are better off using CSP (see below). For general anti-framing protection, you only need to specify X-Frame-Options: deny or X-Frame-Options: sameorigin in your server’s headers.
• Content-Security-Policy with frame-ancestors: The Content-Security-Policy HTTP header (CSP) was initially developed to protect against XSS and other data injection attacks. However, it also provides a frame-ancestors directive for specifying sources that are permitted to embed a page (in a <frame>, <iframe>, <object>, <embed>, or <applet> element). The syntax is simple:

Content-Security-Policy: frame-ancestors <source1> <source2> ... <sourceN>;

You can specify any number of sources, and supported source values include host IPs or addresses, scheme types, 'self' to specify the current document’s origin, and 'none' to disallow all embedding. This gives you a lot of flexibility for defining sources, especially in complex deployments, but for basic protection, the last two options are usually sufficient: frame-ancestors 'self' is equivalent to XFO’s sameorigin directive, while frame-ancestors 'none' corresponds to deny in XFO.

While still not a guarantee of absolute clickjacking safety, the X-Frame-Options HTTP header is still the most universal way of increasing general website resilience, eliminating not just typical clickjacking attempts, but also a host of other vulnerabilities – see this article for a detailed discussion of its benefits. Although the CSP frame-ancestors directive should provide equivalent protection to X-Frame-Options, in practice XFO is still more widely and uniformly supported, even if it’s officially deprecated. If both headers are specified, the CSP spec indicates that frame-ancestors should take precedence and X-Frame-Options should be rejected – but some older browsers (such as Google Chrome 40 and Mozilla Firefox 35) do the reverse. Whichever solution you choose, you can use Netsparker to check your websites both for X-Frame-Options and Content-Security-Policy headers and ensure that your chosen security policies are applied consistently across all pages.Apart from anti-framing schemes on the server side and client side, users are also protected from clickjacking by security features built into modern browsers. The web page rendering process involves multiple layers of checks to ensure that UIs behave as expected by the user, including anti-clickjacking algorithms to counter repositioning and scrolling attacks. Browsers can also block pop-ups and other unusual web page behaviors or warn the user when suspicious operations are attempted.

Why the Clickjacking Threat Is Here to Stay

X-Frame-Options was an interim solution that was widely adopted by browser vendors and CSP’s frame-ancestors directive provides a more standardized and flexible version of the same approach. Both headers can currently provide effective protection against framing and frame-based clickjacking attacks and in the future, frame-ancestors should see universal adoption to prevent iframe abuse. But remember that clickjacking is not about iframes – it’s about deceiving the user and exploiting their trust in what they see in the browser window. With the majority of web browsing traffic now coming from mobile devices, the potential for creating misleading user interfaces is enormous and securing traditional web browser access is no longer enough.