Clickjacking
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Use Trickest to easily build and automate workflows powered by the world's most advanced community tools. Get Access Today:
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.
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 the sandbox attribute with allow-forms or allow-scripts values without allow-top-navigation. This prevents the iframe from verifying if it is the top window, e.g.,
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 to X-Frame-Options: deny.
frame-ancestors 'self' - Similar to X-Frame-Options: sameorigin.
frame-ancestors trusted.com - Similar to X-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.
child-src and frame-srcContent 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.
frame-src DirectiveDefines valid sources for frames.
More specific than the default-src directive.
This policy allows frames from the same origin (self) and https://trusted-website.com.
child-src DirectiveIntroduced in CSP level 2 to set valid sources for web workers and frames.
Acts as a fallback for frame-src and worker-src.
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:
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.
Use Trickest to easily build and automate workflows powered by the world's most advanced community tools. Get Access Today:
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
