Clickjacking 2.0: How an Attacker Can Compromise an Account with a Simple "Double Click"!
After several years, a simple attack technique (published last week) brought ‘Clickjacking’ back to life! When you understand it, you might wonder why nobody thought about it before.
But first, lets rewind back 20 years.
Clickjacking Attack Flow in 2005:
User logs into Facebook > Visits Attackersite[.]com in a new tab.
Attackersite[.]com loads Facebook within its own site (using HTML iframes) and sets it invisible > Overlays the Facebook’s "Like" button with the Attackersite’s "Grab Free iPhone" button.
User clicks on this button > But the click actually lands on the 'Like' button hiding below it > User has no idea this happened.
This attack was solved largely with one simple logic:
Prevent one site from arbitrarily framing another site within it (How? Using "X-Frame-Options" header).
Clickjacking Attack Flow in 2025: (Aka "Double Clickjacking”)
User logs into Facebook > Visits Attackersite.com in a new tab (parent window)
Attackersite.com opens a new window (child window) asking user to "double click" on a button (to prove you are a human 🙂)
The child window now redirects the original parent window to a sensitive Facebook page (e.g., an OAuth authorization page). (This can be easily done by using something like window.opener.location to change the parent window’s location to the target page).
When the user double-clicks:
Click 1: Closes the child window, exposing the parent window.
Click 2: Lands on the Facebook page granting sensitive permissions or hitting the 'Like’.
(Note: Credits to researcher Paulos Yibelo for finding this).
Key Insights:
[1] This is a good example of why hacking is more of an art than science. None of the factors used in this latest attack are new. Its just the stitching together of the known scenarios in a very creative way that led to this new vector (which makes this space so interesting!).
[2] If you play this attack in slow motion, you’ll find this brilliant part: Right before that Click 2, in the blink of an eye, the attacker "swaps in" the actual sensitive page. This is almost like a magician redirecting your attention just long enough to pull off the trick without you noticing.
[3] What makes this attack so dangerous is that it bypasses all existing Clickjacking defenses because 1) it doesn't use iframes, so X-Frame-Options can't help 2) it doesn't pass cookies to another domain, so cookie 'samesite' setting won't help. All the actions occur directly on target site.
[4] How do we stop this? 1) Short term, you can explore the client side JS solution that's published by the researcher (link in comments) 2) Long term, browsers will likely solve this problem by introducing a response header that prevents rapid context switching during double click sequence. 3) Do not allow sensitive Oauth access requests from unauthorized apps.
[5] This isn't just about clickjacking - it's about how security evolves in general. Every "solved" problem is going to be revisited, reimagined, and sometimes exploited again in new ways. In security, we don't solve problems - we just make them harder to exploit… for a while.