Clickjacking ( UI redressing )

In this section, we will explain what Clickjacking is, describe common examples of clickjacking attacks, and discuss how to defend against them.

What is clickjacking

Clickjacking is an interface based attack that induces the user to click on hidden actionable dangerous content in a phishing site.

For example, a user is induced to visit a phishing site (perhaps by clicking on a link in an email) and then click on a button to win a big prize. Instead, the attacker hid a button on another site to make a payment to another account beneath the winning button, and the result was that the user was tricked into making the payment. This is an example of a clickjacking attack. The technique essentially merges two pages using iframe, so that the actual page is hidden and the page that the user is tricked into clicking on is displayed. Clickjacking differs from CSRF attacks in that clickjacking requires the user to perform some action, such as clicking a button, whereas CSRF forges the entire request without the user’s knowledge or input.

The defense against CSRF attacks is usually the CSRF token (a random number used once for a specific session). Clickjacking cannot be mitigated by CSRF token because the target session is established within the content loaded by the real site and all requests occur within the domain. The CSRF token is also put into the request and passed to the server as part of normal behavior, the difference being that this takes place in a hidden IFrame compared to a normal session.

How to construct a basic clickjacking attack

Click hijack attack to create and manipulate layers using CSS. Attackers embed and hide the target website through iframe. The following is an example of using style tags and parameters:

<head> <style> #target_website { position:relative; width:128px; height:128px; Opacity: 0.00001; z-index:2; } #decoy_website { position:absolute; width:300px; height:400px; z-index:1; } </style> </head> ... <body> <div id="decoy_website"> ... decoy web content here... </div> <iframe id="target_website" src="https://vulnerable-website.com"> </iframe> </body>Copy the code

The target website iframe is positioned in the browser to precisely overlap the target action with the decoy website using the appropriate width and height position values. Absolute and relative location values are used to ensure that the target site accurately overlaps with the decoy, regardless of screen size, browser type, and platform. The z-index determines the order in which the iframe and site layers are stacked. Transparency is set to zero, so iframe content is transparent to the user. Browsers may automatically implement clickjacking protection based on thresholds for iframe transparency (for example, Chrome 76 includes this behavior but Firefox does not), but an attacker can still select the appropriate transparency value to achieve the desired effect without triggering this protection behavior.

Pre-fill the input form

Some sites that require form filling and submission allow form input to be prepopulated with the GET parameter before submission. Because the GET parameter is in the URL, an attacker can directly modify the value of the target URL and overlay a transparent “submit” button on the decoy site.

Frame interceptor script

Click hijacking is possible as long as a website can be framed. Therefore, preventive technology is based on limiting the ability of a site frame. A common client-side protection is to use a Web browser’s frame interceptor or cleanup script, such as a browser plug-in or extension, which is often carefully designed to perform some or all of the following:

  • Checks and forces the current window to be either the main window or the top window
  • Make allframeVisible.
  • Block click invisibleframe.
  • Intercept and flag potential clickjacking attacks on users.

Frame interception techniques are generally browser – and platform-specific, and can often be circumvented by attackers due to the flexibility of HTML. Since these scripts are also JavaScript, the browser’s security Settings may prevent them from running, even if the browser does not support JavaScript directly. Attackers can also use the SANDbox property of HTML5 iframe to circumvent frame interception. If the sandbox of the iframe is set to allow-forms or allow-scripts and allow-top-navigation is ignored, the frame interceptor script may not work. Because iframe cannot check if it is a top window:

<iframe id="victim_website" src="https://victim-website.com" sandbox="allow-forms"></iframe>
Copy the code

When allow-Forms and Allow-scripts of iframe are set and top-level navigation is disabled, this inhibits frame blocking behavior while allowing functionality within the target site.

Combine clickjacking with DOM XSS attacks

So far, we have viewed clickhijacking as a separate attack. Historically, clickjacking has been used to perform actions such as adding “likes” to Facebook pages. However, clickjacking can be truly destructive when it is used as a vehicle for another attack, such as DOM XSS attacks. Assuming that the attacker discovers the vulnerability of the XSS attack first, it is simple to perform this combined attack by combining the target URL of the IFrame with XSS to enable the user to click a button or link, thus executing the DOM XSS attack.

Multi-step click hijacking

An attacker may need to perform more than one operation to manipulate the target site’s input. For example, an attacker might want to trick a user into buying an item from a retail site and then adding the item to the shopping basket before placing the order. To do this, an attacker may use multiple views or iframes, which also require considerable precision and must be very careful.

How to defend against clickjacking attacks

We’ve already discussed a browser-side prevention mechanism called frame intercepting scripts. However, it is also often easy for an attacker to bypass this defense. Therefore, server-side driven protocols were designed to limit browser iframe usage and mitigate the risk of clickjacking.

Clickjacking is browser-side behavior whose success depends on the capabilities of the browser and adherence to current Web standards and best practices. The defense on the server side is to define the constraints used by the iframe component, however, the implementation is still up to the browser to follow and enforce these constraints. The two types of server protection against clickjacking are X-frame-options and Content Security Policy.

X-Frame-Options

X-frame-options was first introduced by IE8 as an unofficial response header, and was quickly adopted in other browsers as well. The x-frame-options header provides the site owner with control over iframe usage. For example, you can use deny to deny all iframe references to your site:

X-Frame-Options: deny
Copy the code

Or use SameOrigin to limit references to only homologous sites:

X-Frame-Options: sameorigin
Copy the code

Or use allow-from to specify a whitelist:

X-Frame-Options: allow-from https://normal-website.com
Copy the code

X-frame-options are implemented differently across browsers (for example, Chrome 76 or Safari 12 does not support allow-from). However, as part of a multi-layer defense strategy, it can effectively prevent clickjacking attacks when combined with Content Security Policy.

Content Security Policy

Content Security Policy (CSP) is a detection and prevention mechanism that can mitigate attacks such as XSS and clickjacking. A CSP is typically returned by a Web service as a response header in the following format:

Content-Security-Policy: policy
Copy the code

Where policy is a semicolon-delimited string of policy directives. The CSP provides client browsers with information about permitted Web resource sources that the browser can apply to detect and intercept malicious behavior.

For click-hijacking defense, it is recommended to add frame-rooted Policy to Content-Security-Policy.

  • frame-ancestors 'none'Similar to theX-Frame-Options: denyTo reject all iframe references.
  • frame-ancestors 'self'Similar to theX-Frame-Options: sameorigin, indicating that only same-origin references are allowed.

Example:

Content-Security-Policy: frame-ancestors 'self';
Copy the code

Or specify a whitelist of websites:

Content-Security-Policy: frame-ancestors normal-website.com;
Copy the code

To effectively defend against clickjacking and XSS attacks, CSPS need to be carefully developed, implemented, and tested, and should be used as part of a multi-tiered defense strategy.

As this series continues to be updated, click to view the series on Web security.