clickjacking
Last updated
Last updated
📚 What Is Clickjacking (UI redressing) ?
⚔ Clickjacking Attack Example
🔎 How To Find
🛠 Tools
🛺 Clickjacking mitigation
📕 Referance
🔬 Labs
Clickjacking is an attack that tricks a user into clicking a webpage element that is invisible or disguised as another element.
This can cause users to unwittingly download malware, visit malicious web pages, provide credentials or sensitive information, transfer money, or purchase products online.
Clickjacking is performed by displaying an invisible page or HTML element, inside an iframe, on top of the page the user sees.
The user believes they are clicking the visible page but in fact, they are clicking an invisible element in the additional page transposed on top of it.
Clickjacking attacks use CSS to create and manipulate layers.
The attacker incorporates the target website as an iframe layer overlaid on the decoy website. An example using the style tag and parameters is as follows:
Basic Payload
The attacker creates an attractive page that promises to give the user a free trip to Tahiti.
In the background, the attacker checks if the user is logged into his banking site and if so, loads the screen that enables transfer of funds, using query parameters to insert the attacker’s bank details into the form.
The bank transfer page is displayed in an invisible iframe above the free gift page, with the “Confirm Transfer” button exactly aligned over the “Receive Gift” button visible to the user.
The user visits the page and clicks the “Book My Free Trip” button.
In reality, the user is clicking on the invisible iframe and has clicked the “Confirm Transfer” button. Funds are transferred to the attacker.
The user is redirected to a page with information about the free gift (not knowing what happened in the background).
Find clickjacking vulnerabilities using Burp Suite’s web vulnerability scanner
There are many browsers extensions that inform you when the page is vulnerable to Clickjacking
A basic way to test if your site is vulnerable to clickjacking is to create an HTML page and attempt to include a sensitive page from your website in an iframe. It is important to execute the test code on another web server because this is the typical behavior in a clickjacking attack.
View the HTML page in a browser and evaluate the page as follows:
If the text “Website is vulnerable to clickjacking” appears and below it, you see the content of your sensitive page, the page is vulnerable to clickjacking. ✅
If only the text “Website is vulnerable to clickjacking” appears, and you do not see the content of your sensitive page, the page is not vulnerable to the simplest form of clickjacking. ❌
Burp Clickbandit is a tool for generating clickjacking attacks. When you have found a web page that may be vulnerable to clickjacking, you can use Burp Clickbandit to create an attack and confirm that the vulnerability can be successfully exploited.
There are three main mechanisms that can be used to defend against Clickjacking:
Preventing the browser from loading the page in the frame using the X-Frame-Options or Content Security Policy (frame-ancestors) HTTP headers.
Properly setting authentication cookies with SameSite=Strict (or Lax), unless they explicitly need None (which is rare).
Implementing JavaScript code in the page to attempt to prevent it from being loaded in a frame (known as a “frame-buster”).
X-Frame-Options header There are three values allowed:
DENY – does not allow any domain to display this page within a frame
SAMEORIGIN – allows the current page to be displayed in a frame on another page, but only within the current domain
ALLOW-FROM URI – allows the current page to be displayed in a frame, but only in a specific URI – for example, www.example.com/frame-page
Content Security Policy (CSP)
Content Security Policy (CSP) is a detection and prevention mechanism that provides mitigation against attacks such as XSS and clickjacking. CSP is usually implemented in the web server as a return header of the form:
The recommended clickjacking protection is to incorporate the frame-ancestors directive in the application’s Content Security Policy:
The frame-ancestors ‘none’ directive is similar in behavior to the X-Frame-Options deny directive.
The frame-ancestors ‘self’ directive is broadly equivalent to the X-Frame-Options sameorigin directive. The following CSP whitelists frames to the same domain only:
Alternatively, framing can be restricted to named sites:
Equivalent to the
OWASP Broken Web Applications Project Install this Machine and will have a lot of Labs like DVWA, BWAPP, and Webgoat, etc
