Skip to content
Pwnversity

Clickjacking

The attacker loads the victim site in an invisible iframe over their own page and tricks the user into clicking where they don’t expect (UI redressing). That click runs an action with the victim’s session: change a setting, accept a permission, confirm a payment, give a “like” (likejacking) or even type (cursorjacking).

Threat model

Section titled “Threat model”

Execute one-click or drag actions on the victim’s behalf; chained with no-confirmation flows, it can lead to account changes, permission grants (OAuth) or payments.

Anatomy

Section titled “Anatomy”

It works if the victim page allows framing (sends no X-Frame-Options or CSP frame-ancestors). The attacker overlays their UI (a decoy button/game) over the victim’s real button, which is invisible (opacity 0) but clickable, aligned with the cursor.

Red Team

Section titled “Red Team”

Check if it’s framable

Section titled “Check if it’s framable”
# Does the response carry these headers? If NOT, it's a candidate:
X-Frame-Options: DENY | SAMEORIGIN
Content-Security-Policy: frame-ancestors 'none' | 'self' | <origins>

Build the PoC

Section titled “Build the PoC”
<style>
  iframe{opacity:0.0;position:absolute;top:0;left:0;width:1000px;height:800px;z-index:2}
  #lure{position:absolute;top:/*align with the real button*/;left:/*...*/;z-index:1}
</style>
<div id="lure">Click to win</div>
<iframe src="https://victim.tld/settings/delete-account"></iframe>

Tune the lure’s position so it lands right over the real button. For multi-step actions, use multi-click or drag-and-drop (drag data into an iframe field).

Bypassing weak “frame busting”

Section titled “Bypassing weak “frame busting””

Old frame busting scripts (if(top!=self) top.location=self.location) are bypassed with sandbox="allow-forms allow-scripts" (without allow-top-navigation), the iframe csp attribute, or double framing. The reliable defense is the headers, not JS.

Tooling

Section titled “Tooling”

Burp Clickbandit generates PoCs automatically; the browser to fine-tune the overlay.

Blue Team

Section titled “Blue Team”

Detection

Section titled “Detection”

Sensitive pages served without frame-ancestors/X-Frame-Options; periodic header audits.

Hardening

Section titled “Hardening”
  1. Content-Security-Policy: frame-ancestors 'none' (or allowed origins) — the modern, preferred defense.
  2. X-Frame-Options: DENY (or SAMEORIGIN) for old browsers.
  3. SameSite cookies (makes it harder for the framed action to carry the session) and confirmation/re-authentication on sensitive actions.

Response

Section titled “Response”

Add the headers site-wide (not just on specific pages) and review no-confirmation actions.

CVEs and real-world cases

Section titled “CVEs and real-world cases”
  • Likejacking on social networks (stolen “like” clicks via invisible iframes) was rampant around 2010-2011.
  • Numerous panels and apps have been vulnerable by not sending frame-ancestors/ X-Frame-Options; still appears in bug bounty, with impact depending on the framable action.

CVEs/incidents in NVD (https://nvd.nist.gov/vuln/search) and GitHub Advisories (https://github.com/advisories).

Testing checklist

Section titled “Testing checklist”
  • Can the page be framed? (no frame-ancestors/X-Frame-Options).
  • Clickjacking PoC over an action with real effect.
  • Frame busting (if any) and its bypass tested.
  • Drag-and-drop / multi-step evaluated if one click isn’t enough.

References

Section titled “References”