DoubleClickjacking: A New type of web hacking technique

Understanding the “DoubleClickjacking” Technique

• Core idea: get the user to commit to two clicks.
  • First click is on an overlaid fake UI (e.g., “double‑click here” / CAPTCHA / form button).
  • That overlay closes after the first click, so the second click lands on a sensitive button beneath (e.g., OAuth “Allow”).
• Variants discussed:
  • Doesn’t need literal “double‑click” wording; could be “click once, then confirm.”
  • Possible adaptation using keyboard+mouse (e.g., command-click listening to keydown).
  • Could be wrapped in rage‑click scenarios or clicker‑style CAPTCHAs.

How Common Is Double‑Clicking on the Web?

• One side: double‑clicking on websites is “extremely uncommon” and feels suspicious.
• Others strongly disagree, citing:
  • Less‑technical users who double‑click almost everything, often due to poor understanding of focus.
  • Habits transferred from desktop file explorers.
  • Frustration with slow UIs leading to repeated clicks.
  • Real uses like Google Drive folder navigation, text selection, and layout shifts on sites like YouTube.
• Worn or faulty mice that emit accidental double‑clicks are mentioned as another real‑world source.

Feasibility, Timing, and Preloading

• Concern: exploit seems to rely on near‑instant page loads.
• Counterpoints:
  • Attacker can preload target pages in background tabs.
  • The visible page can delay the “now click again” step until it detects the target is ready, e.g., via a loading spinner.
• Some viewers found the demo unclear and questioned whether it showed a real compromise or just normal auth flows.

Novelty and Relationship to Existing Attacks

• Multiple comments frame this as a variant of long‑known clickjacking/UI‑redressing tricks (bait‑and‑switch clicks, bouncing ads, etc.), not fundamentally new.
• Reference to prior clickjacking against major sites and related CAPTCHA‑style social engineering.

Proposed Mitigations

• Site/app level:
  • Disable critical buttons when the tab is hidden; re‑enable only after a short delay when visible/focused.
  • Add confirmations/CAPTCHAs for high‑risk actions.
  • Avoid taking actions immediately after layout shifts.
• Browser/UX level:
  • Suggestion to ignore clicks for a short time after focus changes or when UI elements newly appear or move.
  • Firefox dialogs delaying button activation cited as partial prior art, though some fear impact on power users.

Broader Security & UX Themes

• Criticism of popups/tabs being able to rearrange window layouts, though some argue this exists for legacy web‑app workflows.
• Several participants mitigate risk personally by disabling JavaScript by default, using NoScript/uBlock, or Firefox containers.
• Irony noted that the article page itself uses intrusive smooth scrolling/scrolljacking, which many find unusable or motion‑inducing.