A clickjacking attack is usually accompanied by some form of social engineering to lure targets to a compromised link. This article discusses the types of clickjacking attacks, their various impacts, and best practices to prevent them.
Clickjacking attack, also known as User Interface (UI) Redressing, is a web application attack where the hacker tricks a user into clicking an invisible web page element. The hackers set up multiple opaque or transparent layers. Hence, the user clicks a button or link that may cause them to visit malicious pages, download malicious software, transfer funds or give away sensitive data. Using an iFrame on top of a regular web page to display an invisible HTML element or web page performs a typical clickjacking attack.
For ordinary users, clickjacking attacks are hard to detect since they include a malicious application link within an invisible frame. A successful clickjacking attack risks exposing a user’s sensitive data, such as security card numbers or login credentials. Though the clickjacking vulnerability is considered medium risk since it requires the user to interact with the malicious page/element directly, the level of impact for a successful attack varies depending on the application environment, the types of users exposed and the type of data obtained. Some malicious actions that attackers typically perform through clickjacking attacks include:
- Microphone or webcam activation
- Theft of login credentials
- Illegal authorization of funds transfer
- Location exposure
- Invitation to download malware
Whether they rely on overlay content, clickjacking attacks can be categorized into two major groups.
These clickjacking attacks are the most popular ones that rely on embedding malicious content in invisible frames. Common types of overlay-based attacks include:
This is a typical overlay attack where the legitimate page/link is overlaid over a malicious page created by the hacker. The hacker positions the tool page into an invisible iFrame then places it over the visible elements by setting a lower opacity. The unsuspecting user clicks on the legitimate link, activating the tool page, redirecting the browser to execute a malicious script, or visiting an unintended web page.
In this type of overlay, the attacker only blocks a part of the legitimate content by cropping it out by blocking some buttons using malicious hyperlinks to trigger actions that initiate the attack. For instance, an attacker would overlay a new question over the original one on a popup window, leaving the original ‘Allow’ and ‘Cancel’ links active. In such instances, the end-user ends up assuming he is clicking legitimate links for the question.
The earliest demonstrated form of clickjacking attack, the hidden overlay method, involves loading malicious content onto a 1×1 iFrame, so the user can’t see the clickable elements. The iFrame content is placed under the cursor, so the end-user inevitably clicks on it.
The hackers develop malicious content but completely hide it behind the legitimate content. They then ensure click events fall through to the malicious page by setting the CSS pointer-events property of the top layer to none. This means that all click events only register to their malicious elements.
Even without using overlays, hackers can perform clickjacking through:
Hackers partly scroll a portion of a popup or other web elements of the display, so the user can only access some controls. This may involve the attacker scrolling a warning dialogue box off the screen so that only the action buttons are accessible, luring the unsuspecting user with suspicious text. The users assume that these actions apply to the attacker’s hidden message instead of the actual warning in the dialogue box.
In this type of clickjacking attack, the hackers trick the user into performing a drag operation rather than a click. For instance, this may involve overlaying the right/left edge of a trusted window with a depiction of a scroll bar. When users try scrolling using the bar, they initiate a drag operation that exposes or drops sensitive information from the trusted window into a malicious page accessible to the hacker.
In this case, the attacker obscures the victim content until the exact moment when the user is about to click. The hacker then rapidly removes the obscuring content with a malicious link, which prompts the user to click, thinking they are performing the legitimate action.
Over some time, clickjacking attack has evolved into several use-case-specific hacks. Some examples include:
A form of UI redress popular on social media platforms tricks users into ‘liking’ posts and promotions they never intended to. The hacker’s Facebook page/post is embedded in an iFrame, so users don’t realize they are clicking on an invisible ‘Like’ button.
In this form of attack, the hackers change the cursor’s position, so it is not where the victim perceives it to be. As a result, the victim thinks he is clicking on an intended link with a fake cursor, while the actual cursor, which is pointing to another element, clicks on a phony link.
Hackers use available UI redressing techniques to steal a victim’s cookies. They can then read information from the cookie, then use it to steal the user’s identity by obtaining their session. The drag-and-drop clickjacking attack typically achieves Cookiejacking, where the cookie data is exposed when users think they are dropping content into a page element.
This attack relies on the ability of modern web browsers to navigate through local file systems on the victim’s computer. For instance, a file explorer window appears when a user tries to upload a photo on social media. In a filejacking attack, the ‘Click to add files’ button establishes an active file server that attackers can use to access an entire file system.
Since attackers frame the targeted webpage with malicious iFrames, most clickjacking attacks mitigation techniques revolve around restricting framing. Some practical ways of ensuring protection against clickjacking attacks include:
Framebusting is a client-side mitigation technique that involves the use of code to prevent a web page from being loaded within an iframe. To achieve this, developers annotate code with a frame-breaking script that consists of a conditional statement and a counteraction that eliminates the overlay. An example of a simple frame busting script would look similar to:
i f ( top . l o c a t i o n != l o c a t i o n )
top . l o c a t i o n = s e l f . l o c a t i o n ;
Framebusting can protect web pages loaded in all significant and legacy browsers since the modification is done to HTML code, not HTTP headers.
X-Frame-Options is an HTTP response header that determines whether a browser can render a page within an iframe. It proves to be an effective defense against clickjacking attacks since developers use it to ensure that web content is not embedded into frames of other sites. To do so, developers set the X-Frame-Options header for all header responses that contain HTML content.
This includes using three possible value types:
- DENY – prevents all websites from framing content
- SAMEORIGIN – allows only the current website to frame content
- ALLOW-FROM – allows content from the specified URL to frame content
The frame-ancestors attribute can be used within a CSP HTTP response header to determine whether it can render the page within a frame or an iframe. By ensuring the legitimate content is not embedded within other sites, developers can prevent clickjacking attacks. There are three options for frame-ancestors:
- Content-Security-Policy: frame-ancestors ‘none’; – prevents any site from framing the content.
- Content-Security-Policy: frame-ancestors ‘self’; – allows the current site to frame page contents.
- Content-Security-Policy: frame-ancestors ‘self’ *.darwin.com https:// darwin.site.com; – allows the current site, any page on darwin.com (reference website) and only the page on darwin.site.com using HTTPS on the default port.
Crashtest Security Suite’s vulnerability scanner helps prevent clickjacking attacks by scanning security headers for frame-ancestors and X-Frame-Options compatibility. To know more about how Crashtest Security can help reduce clickjacking attacks through continuous testing, try the automated vulnerability scanner now for free and start finding vulnerabilities in your web app or APIs.
This article has already been published on https://crashtest-security.com/clickjacking-attack/ and has been authorized by Crashtest Security for a republish.