Clickjacking (correction de l'interface utilisateur)

Context

Clickjacking is a malicious technique that relies on a user interface to trick a user into clicking on a hidden, exploitable content on a website by clicking on another content present on a trapped website. For instance, a user could go to a decoy website (e.g., through a link received by email) and click on a button to try to win a prize. Unbeknownst to the user, they were fooled by a hacker because by clicking on that button, they actually triggered the execution of a hidden action, such as a payment to another site. This attack requires the integration of one or more invisible and exploitable web pages containing a hidden button or link, which can be inserted in an iframe. This iframe is overlaid on top of the content of the decoy website that the user expected to see. Unlike a CSRF attack, where the forgery of an entire request is done without the user's knowledge, a clickjacking attack requires that the user performs an action, such as clicking on a button.

Protection against CSRF attacks is often provided by the use of a CSRF token: a session-specific, one-time-use, or nonce number. However, clickjacking attacks cannot be prevented with a CSRF token because a target session is established with content loaded from a legitimate website and all requests are executed on the same domain. CSRF tokens are included in requests and transmitted to the server as part of a normal session, but in the case of a clickjacking attack, the process takes place in a hidden iframe, which distinguishes this attack from a normal user session.

How to Build a Basic Clickjacking Attack

Clickjacking attacks can use CSS techniques to create and manipulate layers. In this type of attack, the attacker embeds the target website as an iframe layer overlaid on the decoy website. Here is an example of the use of the tag and style parameters:

 <head>
	<style>
		#website {
			position:relative;
			width:130px;
			height:130px;
			opacity:0.00004;
			z-index:2;
			}
		#decoy_website {
			position:absolute;
			width:400px;
			height:400px;
			z-index:1;
			}
	</style>
</head>
...
<body>
	<div id="decoy_website">
	...decoy web ...
	</div>
	<iframe id="website" src="https://website.com">
	</iframe>
</body>

Clickjacking Attack

In a clickjacking attack, the attacker positions the target website's iframe in the browser so that the target action precisely overlaps the decoy website. To achieve this, the attacker uses appropriate position, width, and height values for the elements, using absolute and relative position values to ensure that the overlap is precise, regardless of the screen size, browser, and platform used. The z-index is also used to determine the stacking order of the iframe and website layers.

To make the iframe invisible to the user, the attacker sets the opacity value to 0.0 (or close to 0.0). This transparency can be detected by some clickjacking protection features in browsers, which can apply an iframe transparency detection based on a threshold. For example, version 76 of Chrome includes this feature, but not Firefox. To avoid being detected by these features, the attacker selects opacity values that achieve the desired effect without triggering protection behaviors.

Clickjacking with Pre-Filled Form Input

Some websites allow users to fill out and submit forms, and may also offer the ability to pre-fill form inputs using GET parameters before submission. In other cases, websites may require the user to enter text before being able to submit the form. In a clickjacking attack, the attacker can take advantage of this feature to modify the target URL and incorporate the values chosen by the attacker. Then, a transparent "Submit" button can be overlaid on the decoy website, simulating a legitimate action for the user, while the actual form submission is performed on the target website without the user's consent.

Frame Busting Scripts

Clickjacking attacks are possible on any website that allows iframes to be embedded. To protect against these attacks, a common client-side protection is to use frame-busting scripts. These scripts can be implemented via add-ons or proprietary JavaScript extensions for web browsers, such as NoScript.

Frame-busting scripts are often designed to perform various security behaviors, including verifying and enforcing that the current application window is the main or top window, making all frames visible, preventing clicking on invisible frames, intercepting and reporting potential clickjacking attacks to the user.

However, frame-busting techniques are often browser- and platform-specific, and due to HTML's flexibility, they can be bypassed by attackers. For example, since frame busters are written in JavaScript, browser security settings may prevent them from working, or even the browser may not support JavaScript.

An effective workaround against frame busters is to use the HTML5 iframe sandbox attribute. This limits the capabilities of the iframe, thereby preventing the clickjacking attack from occurring.

 <iframe id="website" src="https://website.com" sandbox="allow-forms"></iframe>

Using the HTML5 iframe sandbox attribute, the allow-forms and allow-scripts values enable certain specified actions to run within the iframe, while disabling top-level navigation. This blocks frame-busting behaviors while allowing functionality within the target site.

The allow-forms attribute enables the use of forms in the iframe, while the allow-scripts attribute enables the execution of scripts in the iframe. By limiting the scope of these features within the iframe, the risks of clickjacking and other similar attacks are reduced, as malicious scripts cannot affect the navigation of the parent site.

Combining Clickjacking with a DOM XSS Attack

Clickjacking has long been considered a standalone attack, typically used for behaviors such as driving "likes" on a Facebook page. However, the real power of this technique lies in its use as a support for other attacks, such as the DOM XSS attack. By combining clickjacking with a previously identified XSS exploit, it becomes relatively simple to execute a DOM XSS attack. To do this, the XSS exploit is associated with the target URL of an iframe, prompting the user to click on a button or link and allowing the execution of the DOM XSS attack.

Multi-Step Clickjacking

Manipulating inputs of a target website can involve multiple steps for an attacker. For example, the attacker may seek to trick a user into making a purchase on an online shopping site, which may require adding items to the cart before the order is placed. To do this, the attacker may use multiple divs or iframes. However, these attacks require great precision and careful attention from the attacker to be effective and go unnoticed.

Preventing Clickjacking Attacks

We have discussed frame-busting scripts as a common browser-side prevention measure against clickjacking. However, these protections are often easy for an experienced attacker to bypass. For this reason, server-driven protocols have been developed to limit the use of iframes in the browser and to mitigate clickjacking.

The success or failure of clickjacking depends on the browser's functionality and compliance with web security standards and best practices. To offer effective protection against this attack, constraints must be defined and communicated to limit the use of certain components such as iframes. However, implementing this protection depends on the browser's compliance and enforcement of these constraints. Two commonly used mechanisms for server-side protection against clickjacking are X-Frame-Options and Content Security Policy.

X-Frame-Options

X-Frame-Options was initially introduced as an unofficial response header in Internet Explorer 8, but it quickly gained adoption by other browsers. The goal of this header is to enable website owners to control the use of iframes and objects, by allowing them to prohibit the inclusion of a web page within a frame using the "deny" directive. Alternatively, framing can be limited to the same origin as the website using the sameorigin or allow-from directive.```

 X-Frame-Options: deny
X-Frame-Options: sameorigin
X-Frame-Options: allow-from https://website.com

While the implementation of X-Frame-Options may vary between browsers, this technique can offer effective protection against clickjacking attacks when properly applied in conjunction with a content security policy as part of a multi-layered defense strategy.

Content Security Policy (CSP)

The Content Security Policy (CSP) is a prevention and detection mechanism that provides protection against attacks such as clickjacking and XSS attacks. To do this, the CSP is typically implemented at the web server level in the form of a header returned with the form:

Content-Security-Policy: default-src 'self'; frame-ancestors 'self'

This header specifies which resources the browser should consider as trusted sources and which should be blocked. For example, the 'default-src' directive specifies which sources of content the browser should consider as valid sources, while the 'frame-ancestors' directive specifies which origins are allowed to embed the page in an iframe. By configuring these directives to limit the use of iframes and other sources of potentially malicious content, the CSP can effectively mitigate clickjacking attacks and other similar attacks.

In summary, preventing clickjacking attacks requires a multi-layered defense strategy that includes both browser-side and server-side protections. By properly implementing X-Frame-Options and Content Security Policy, website owners can significantly reduce the risks of clickjacking and other similar attacks.

 Content-Security-Policy: policy

The CSP uses a string of policy directives separated by semicolons to provide the client browser with information about authorized sources of web resources, which can help detect and intercept malicious behaviors.

To protect against clickjacking, it is recommended to incorporate the frame-ancestors directive into the content security policy of the application. If the value 'none' is used, this directive will behave similarly to the X-Frame-Options "deny" directive. However, to allow frames from the same domain to be included, it is possible to whitelist those frames using the following CSP:

 Content-Security-Policy: frame-ancestors 'self';
Content-Security-Policy: frame-ancestors website.com;

Alternatively, framing can be limited to named sites using the CSP directive: