Luke a Pro

Luke Sun

Developer & Marketer

đŸ‡ș🇩
EN|缀|çč
© 2015–2026 Luke Sun.
All rights reserved.

Clickjacking (UI Redress Attack)

| , 4 minutes reading.

1. Definition

Clickjacking (also known as “UI Redress Attack”) is a malicious technique where an attacker tricks a user into clicking on something different from what the user perceives. The attacker loads a target website in a transparent iframe and overlays it on top of a decoy page, causing clicks on the visible page to actually register on the hidden target.

This allows attackers to hijack clicks intended for the visible page and redirect them to perform unintended actions on another site where the user is authenticated.

2. Technical Explanation

The attack exploits the browser’s ability to layer web content using CSS positioning and opacity.

Attack Structure:

<!-- Attacker's Page -->
<style>
  iframe {
    position: absolute;
    top: 0;
    left: 0;
    width: 500px;
    height: 200px;
    opacity: 0;        /* Invisible */
    z-index: 2;        /* On top */
  }
  .decoy-button {
    position: absolute;
    top: 50px;
    left: 100px;
    z-index: 1;        /* Below iframe */
  }
</style>

<button class="decoy-button">Click to Win a Prize!</button>
<iframe src="https://bank.com/transfer?to=attacker&amount=1000"></iframe>

When the user clicks the “Win a Prize” button, they actually click the invisible “Transfer” button on bank.com.

Key Conditions:

  1. Target site allows embedding in iframes.
  2. User is authenticated on the target site.
  3. The target action can be triggered with a single click.

3. Attack Flow

sequenceDiagram
    participant Victim
    participant AttackerPage as Attacker Page
    participant TargetSite as Target Site in iframe

    Victim->>AttackerPage: Visits malicious page

    Note over AttackerPage: Page loads target site<br/>in invisible iframe

    AttackerPage-->>Victim: Shows decoy content<br/>Win a Prize button

    Victim->>AttackerPage: Clicks decoy button

    Note over Victim,TargetSite: Click passes through<br/>to invisible iframe

    Victim->>TargetSite: Actual click on Delete Account button

    TargetSite-->>TargetSite: Action executed<br/>Account deleted

    TargetSite-->>Victim: Confirmation page in hidden iframe

4. Real-World Case Study: Twitter Worm (2009)

Target: Twitter “Follow” button functionality. Vulnerability Class: Classic Clickjacking / UI Redress.

The Vulnerability: In 2009, Twitter did not implement frame-busting or X-Frame-Options headers. Any page could embed Twitter in an iframe.

The Attack:

  1. Attackers created pages with enticing content like “Don’t Click This” or fake Flash player buttons.
  2. Behind these buttons was an invisible iframe containing Twitter’s Follow button for a specific account.
  3. When users clicked, they unknowingly followed the attacker’s Twitter account.
  4. The followed account then sent Direct Messages with links to the same malicious page.

Impact: The worm spread virally, with some accounts gaining hundreds of thousands of followers in hours. It demonstrated how clickjacking could enable self-propagating attacks on social platforms.

5. Detailed Defense Strategies

A. X-Frame-Options Header

The classic defense against framing attacks.

X-Frame-Options: DENY
  • DENY: Page cannot be displayed in any frame.
  • SAMEORIGIN: Page can only be framed by pages from the same origin.

Note: This header is now considered legacy. Use CSP frame-ancestors instead.

B. Content-Security-Policy: frame-ancestors

The modern and more flexible approach.

Content-Security-Policy: frame-ancestors 'self' https://trusted-partner.com
  • 'none': Equivalent to X-Frame-Options: DENY.
  • 'self': Only same-origin can frame.
  • Specific domains: Allowlist trusted embedders.

C. JavaScript Frame Busting (Fallback)

A legacy technique for older browsers that do not support headers.

// Basic frame buster
if (top !== self) {
  top.location = self.location;
}

Warning: This can be bypassed with sandbox attribute:

<iframe src="target.com" sandbox="allow-scripts"></iframe>

Modern defense should rely on HTTP headers, not JavaScript.

D. SameSite Cookies

Even if framed, prevent session cookies from being sent in cross-site iframe contexts.

Set-Cookie: session=abc123; SameSite=Strict; Secure

This breaks the attack because the target site will not recognize the user as authenticated.

E. User Interaction Confirmation

For critical actions, require additional confirmation:

  • Re-authentication: Require password for sensitive operations.
  • CAPTCHA: Proves human intent.
  • Two-step actions: Require explicit confirmation dialog.

6. References