In our last blog, we discussed how OAuth-based consent phishing attacks have been used to trick users into giving malicious apps the permission to conduct malicious activities via an employee’s account. This attack has been extremely effective due to the lack of awareness of how attackers can misuse OAuth permissions. Now, let’s say we are in an ideal world where with ample security training most employees are now aware of consent phishing and scrupulously reads every OAuth permissions request, will we truly be immune to OAuth identity attacks? Paulos Yibelo’s recent unveiling of double-clickjacking attacks suggests otherwise. This new attack mechanism exploits the routine double-click action to open up the OAuth screen for a split second in between clicks, deceiving users into authorizing a permission without them even knowing. These screen changes happen so fast that it is impossible for even the most vigilant user to know they have become victims to a double-clickjacking attack. This article will explore the details on double-clickjacking works, how it’s different from traditional clickjacking and the ultimate question of how do we even stop something that we don’t know is happening?
A Trip Down Memory Lane: Revisiting Clickjacking
For those who have spent some time in security, clickjacking is likely not an unfamiliar term. Clickjacking is a technique attackers use to manipulate users into clicking on something different from what they perceive. This could involve tactics such as embedding disguised/ invisible buttons, manipulating iframe layers or cursorjacking, where the attacker alters the position of the cursor such that the cursor’s real position is different from what users see.
How have we dealt with clickjacking?
From Facebook’s likejacking attacks to Twitter’s war against clickjackers, the early 2010s saw a slew of clickjacking attacks targeting major social media platforms and brands. Since then, clickjacking has largely become solvable in two ways: From the user side (Same Site: Lax)”Š”, “Šmost modern browsers now prevent cross-site cookies with the “Same Site: Lax” setting. This cookie setting allows cookies to be sent for top-level navigations (e.g. by clicking links or typing URLs), but does not send cookies to third-party sites or embedded elements. For example, if a user navigates from origin.com to example.com directly, the cookie will be sent. However, if example.com was loaded inside an iframe on a third-party website, or if the request is made from a script embedded on another site, the cookie will not be sent. From the app/website developer side (X-Frame-Options)”Š”, “Šwebsite developers have also leveraged the X-Frame Options header to control how their web page can be embedded within an iframe or other frame-based elements on another website. For example, DENY blocks any framing and SAMEORIGIN only allows for the page to be framed by the same domain. This helps prevent their brand or app from being used to manipulate victims in a clickjacking attack.
How is Double-clickjacking Different from Traditional Clickjacking?
Given that current security measures used to tackle clickjacking work by controlling embedded elements or cross-site interactions, they do not address double-clickjacking, which manipulates user interactions with elements on the same page and often does not rely on embedding.
The Impact of Double-clickjacking
As double-clickjacking can work on pretty much any website, there are countless ways in which attackers can leverage this technique. Some examples include:
- Provide malicious apps access to SaaS accounts to:
Write and send malicious emails on the user’s behalf Copy, delete or hold a developer’s code hostage Read all the documents stored on sites like OneDrive and GoogleDrive Observe live feeds of video streaming platforms like Google Meets Publish malicious updates to an extension/app on official stores 2. Authorize payments from a e-wallet or digital payments platform 3. Change/disable account security settings 4. Submit forms containing credentials or sensitive data 5. Delete accounts and/or sensitive data
How Double-clickjacking OAuth Attacks Works
To illustrate how double-clickjacking works, this article will focus on OAuth attacks and an example. Here is a typical sequence of double-clickjacking used in an OAuth identity attack:
- An employee lands on an attacker’s website. We will call this the “parent window”. The employee clicks on a button, which opens up a new window, the “child window”, which contains a prompt for the user to double-click. When the child window opens, it utilizes window.opener.location function to prompt the parent window to navigate to the target OAuth page. When the user double clicks, the following happens: The first click triggers a mouse-down event which closes the child window, exposing the parent window. The second click accepts the scope/permissions requested via OAuth by the malicious app.
The button on the child window is positioned such that it is right on top of the “accept” button on the OAuth page. The double-click motion is so fast that users frequently don’t even realize that they gave authorized access to a malicious app. As seen above, no iframes or cross-site authentications were involved in this sequence. Thus, double-clickjacking attacks are completely unaffected by current measures used to defend against clickjacking attacks.
Preventing Double-clickjacking Attacks
If traditional measures don’t work, how can one defend against double-clickjacking attacks? Given that it is impossible to ban double-clicks, the answer resides in preventing what the attack is intended to do. Using the OAuth attack as an example, security teams can prevent malicious apps from accessing employee accounts by blocking all OAuth permission granting for unauthorized apps. The video below showcases how SquareX’s Browser Detection and Response (BDR) solution can monitor and control all OAuth requests to corporate apps like GitHub. medium.com/media/1f8e75d52056c7a4103d795ab9c4a12e/href
Introducing the BDR
SquareX’s Browser Detection and Response (BDR) solution goes beyond just protecting against consent phishing and identity-based attacks. SquareX’s industry-first BDR solution detects, mitigates and threat-hunt client-side web attacks targeting employees in real time. The solution comes in the form of a lightweight browser extension that can be deployed to existing browsers via a simple group policy. We believe that there are three key components required when it comes to securing the browser: Web Threat Detection & Mitigation including identity attacks, malicious sites & scripts, malicious browser extensions and malicious files Browser DLP including genAI DLP, clipboard DLP, file DLP and insider attacks Private App Access to provide secure access to web applications and private apps via the browser, including for BYOD/unmanaged devices
Two Clicks to Chaos: How Double-clickjacking Hands Over Control of Apps without Users Knowing was originally published in SquareX Labs on Medium, where people are continuing the conversation by highlighting and responding to this story.
First seen on securityboulevard.com
Jump to article: securityboulevard.com/2025/01/two-clicks-to-chaos-how-double-clickjacking-hands-over-control-of-apps-without-users-knowing/
