DoubleClickjacking: A New type of web hacking technique

Original Article ↗ Hacker News Discussion ↗

A newly described “doubleclickjacking” technique reimagines classic clickjacking by getting users to commit to two rapid clicks, then using a popup to divert the first click and let the second land on a hidden authorization or consent button beneath. Commenters debate how realistic the attack is in practice, noting that double-click behavior remains surprisingly common—especially among less technical users, during slow page loads, or due to faulty mice—and that similar bait‑and‑switch UI patterns have existed for years. Many argue that better browser‑level defenses and UX patterns, such as briefly disabling clicks after focus changes or layout shifts, would mitigate both this attack and broader usability problems.

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.