hunt-clickjacking
Hunt Clickjacking — missing X-Frame-Options / CSP frame-ancestors lets an attacker embed the target page in an invisible iframe and trick victims into clicking buttons they cannot see (UI redressing). Targets: login flows, money transfers, account settings, OAuth confirmation pag
Install
npx skills add https://github.com/elementalsouls/Claude-BugHunter/tree/main/skills/hunt-clickjacking
claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install elementalsouls-claude-bughunter@llmmart
git clone https://github.com/elementalsouls/Claude-BugHunter.git
The skills CLI installs just this skill, for any of its supported agents. Claude Code installs the whole elementalsouls/claude-bughunter collection as a plugin from our marketplace. Git is the plain clone.
Skill manifest
What is Clickjacking
Clickjacking (UI Redressing) lets an attacker load a target page inside a transparent iframe on a malicious site. The victim sees the attacker's decoy UI but clicks the hidden target UI beneath it. No JavaScript on the target is required.
Highest-value targets:
- Login / authentication pages — force login with attacker credentials
- Money transfer / checkout / "confirm payment" buttons
- Account settings (email change, password change, 2FA disable)
- OAuth / social-login "Authorize app" confirmation dialogs
- Admin actions (delete, promote user, change role)
Protection Headers
Two mechanisms prevent framing:
X-Frame-Options: DENY # strongest — blocks all framing
X-Frame-Options: SAMEORIGIN # allows same-origin frames only
Content-Security-Policy: frame-ancestors 'none' # CSP equivalent of DENY
Content-Security-Policy: frame-ancestors 'self' # CSP equivalent of SAMEORIGIN
If NEITHER is present, the page is frameable from any origin.
How to Test
Header-absence is the trigger for investigation, not the finding. Two steps:
Step 1 — Header check (screening). Fetch the target page and inspect the response headers:
curl -sI https://target.example/account/transfer | grep -iE 'x-frame-options|content-security-policy'
If BOTH X-Frame-Options and CSP frame-ancestors are absent, the page is a candidate. If either is present and restrictive (DENY/SAMEORIGIN/frame-ancestors 'none'|'self'), stop — it's protected.
Step 2 — Prove it actually frames and clicks (required for a real finding). Build a minimal PoC and load it in a real browser:
<!doctype html>
<h1>Win a prize — click below</h1>
<iframe src="https://target.example/account/transfer"
style="opacity:0.1;position:absolute;top:0;left:0;width:1000px;height:800px"></iframe>
Confirm ALL of the following, or it is not exploitable:
- The page actually renders inside the iframe (no framebusting JS that blanks/redirects it — e.g.
if(top!==self)breakout, or aSec-Fetch-Dest/JS frame check). - The sensitive action still works while framed — critically, the action must succeed cross-site. If it relies on a session cookie set
SameSite=LaxorSameSite=Strict(the modern default), the cookie is not sent on the cross-site framed request, and the clickjack fails. Verify the victim's authenticated state carries into the frame. - The target is a state-changing action (transfer, settings/email/password change, 2FA disable, OAuth authorize, admin action), not a read-only page.
Strategy: target the most sensitive action pages first — severity scales directly with what the victim is tricked into doing.
False Positives
- Public, read-only pages (home/marketing) lacking frame protection are low/informational — no sensitive action to redress.
- APIs and non-HTML endpoints (JSON, images) are not clickjacking targets.
- Header-absence alone is NOT a finding. SameSite cookies, framebusting JS, or the lack of any sensitive framed action can each fully defeat it — which is why Step 2 is mandatory.
Proof Requirements
A valid clickjacking report shows: (1) the target page rendered inside an attacker-controlled iframe in a real browser, (2) a sensitive state-changing action reachable by a framed click while the victim is authenticated (cookies survive the cross-site context), and (3) a screenshot/recording of the overlay. Reporting missing headers with no working frame PoC is a documentation-quality issue, not a vulnerability.
Files (claude-bughunter)
-
SKILL.md 4.1 KB
--- name: hunt-clickjacking description: "Hunt Clickjacking — missing X-Frame-Options / CSP frame-ancestors lets an attacker embed the target page in an invisible iframe and trick victims into clicking buttons they cannot see (UI redressing). Targets: login flows, money transfers, account settings, OAuth confirmation pages. Confirm by fetching the page, then PROVE it frames in a real browser and a sensitive state-changing action survives the cross-site context (SameSite cookies / framebusting JS can defeat it) — header-absence alone is not a finding." sources: hackerone_public, public_research report_count: 6 --- ## What is Clickjacking Clickjacking (UI Redressing) lets an attacker load a target page inside a transparent iframe on a malicious site. The victim sees the attacker's decoy UI but clicks the hidden target UI beneath it. No JavaScript on the target is required. **Highest-value targets:** - Login / authentication pages — force login with attacker credentials - Money transfer / checkout / "confirm payment" buttons - Account settings (email change, password change, 2FA disable) - OAuth / social-login "Authorize app" confirmation dialogs - Admin actions (delete, promote user, change role) ## Protection Headers Two mechanisms prevent framing: ``` X-Frame-Options: DENY # strongest — blocks all framing X-Frame-Options: SAMEORIGIN # allows same-origin frames only Content-Security-Policy: frame-ancestors 'none' # CSP equivalent of DENY Content-Security-Policy: frame-ancestors 'self' # CSP equivalent of SAMEORIGIN ``` If NEITHER is present, the page is frameable from any origin. ## How to Test Header-absence is the **trigger for investigation, not the finding**. Two steps: **Step 1 — Header check (screening).** Fetch the target page and inspect the response headers: ``` curl -sI https://target.example/account/transfer | grep -iE 'x-frame-options|content-security-policy' ``` If BOTH `X-Frame-Options` and CSP `frame-ancestors` are absent, the page is a *candidate*. If either is present and restrictive (`DENY`/`SAMEORIGIN`/`frame-ancestors 'none'|'self'`), stop — it's protected. **Step 2 — Prove it actually frames and clicks (required for a real finding).** Build a minimal PoC and load it in a real browser: ```html <!doctype html> <h1>Win a prize — click below</h1> <iframe src="https://target.example/account/transfer" style="opacity:0.1;position:absolute;top:0;left:0;width:1000px;height:800px"></iframe> ``` Confirm ALL of the following, or it is not exploitable: - The page **actually renders inside the iframe** (no framebusting JS that blanks/redirects it — e.g. `if(top!==self)` breakout, or a `Sec-Fetch-Dest`/JS frame check). - The **sensitive action still works while framed** — critically, the action must succeed *cross-site*. If it relies on a session cookie set `SameSite=Lax` or `SameSite=Strict` (the modern default), the cookie is **not** sent on the cross-site framed request, and the clickjack fails. Verify the victim's authenticated state carries into the frame. - The target is a **state-changing action** (transfer, settings/email/password change, 2FA disable, OAuth authorize, admin action), not a read-only page. **Strategy:** target the most sensitive action pages first — severity scales directly with what the victim is tricked into doing. ## False Positives - Public, read-only pages (home/marketing) lacking frame protection are low/informational — no sensitive action to redress. - APIs and non-HTML endpoints (JSON, images) are not clickjacking targets. - **Header-absence alone is NOT a finding.** SameSite cookies, framebusting JS, or the lack of any sensitive framed action can each fully defeat it — which is why Step 2 is mandatory. ## Proof Requirements A valid clickjacking report shows: (1) the target page rendered inside an attacker-controlled iframe in a real browser, (2) a sensitive state-changing action reachable by a framed click while the victim is authenticated (cookies survive the cross-site context), and (3) a screenshot/recording of the overlay. Reporting missing headers with no working frame PoC is a documentation-quality issue, not a vulnerability.
Comments (0)
Sign in to join the conversation.
Reviews (0)
No reviews yet.
No comments yet.