English
+370 5 205 5502 sales@monovm.com

What are Clickjacking Attacks and How to Avoid Them?

Nowadays, clickjacking attacks are more common than ever before. In this article, we will explain what they are and how to avoid them.

20 Apr, 21 by Antoniy Yushkevych 16 min Read

List of content you will read in this article:

Have you ever come across a link that would look enticing and you want to click on ahead and check what's more in it? Such links, games, and other things would seem enticing at first, but they can prove to be dangerous for you. Using such misleading links that will make you want to click on it is called "Clickjacking". 

Clickjacking is an attack wherein the user is tricked into clicking a website or any page element without his/her intention. This term is derived from "click hijacking", and this technique is utilized on websites by cloaking questionable content on a trusted website. It is also done by placing a specific page on top of a visible page. When the user clicks on this visual page, they believe that it is just a standard page, but it is something else in reality. 

The user is actually on a specific location of that page which will cause a suspicious action to get triggered. It can include fake likes on the social media pages so that attackers can pump out all the money from the bank account of the clickjacked user. 

A number of these clickjacking attacks make the most of vulnerabilities based on HTML iframes. Security methods mainly involve page-framing prevention. We will understand how clickjacking is done, how we can avert it, and why this threat will soon disappear. Clickjacking is defined as an example of a "confused deputy problem", where the system is hoodwinked into abusing too much of its authorization.

One of the most common approaches to a clickjacking attack is showcasing the user with a mixture of two shrouded web pages in the browser, plus an added incentive of clicking on a specific spot that would initiate the clickjacking operation. The hacker will then load the unprotected target website into the HTML iframe, set it to a transparent version of it, and then place the iframe in that suspicious web page created for extracting clicks in some suitable spots. 

If we take an instance, we see several browser-related games while looking at some particular web pages. These games are displayed in the form of pop-ups, and after clicking on it, it will say that playing this will let you win cash rewards or prizes, etc. It looks enticing, and it will display the game in the form of a background page, and the actual target website can be a banking application that you usually utilize. 

It can also be an e-commerce website that is overlaid on a transparent frame, as discussed above. The hacker will then create a game site with loads of click options in the same position as those controls of the target site. When you click on these items, the user clicks on those target controls that the hacker wants them to click on, leading to potential financial consequences. 

As per the site that is utilized, the user would be sending positive reviews unknowingly. It can include liking Facebook pages, giving them positive thoughts, authorizing Facebook applications to access your data, log in using Single Sign-On, or even using single-click shopping applications to purchase costly items for the hacker. 

If you combine this with the drag and drop techniques, the hacker will trick the user into filling out form fields, filling out a CAPTCHA, etc. In such cases, structurally prepared interactions with the game will cause the user to unseemingly do a drag and drop operation on the invisible and place it on the form fields. It is therefore essential that users be vigilant when navigating into these unknown pages. 

The first instance of clickjacking was identified in 2002 when an example noted that one could load a transparent layer over a webpage. It would affect the user's input without them noticing anything. This instance was deemed minor and was largely ignored as a significant issue until 2008.

Web application security experts Robert Hansen and Jeremiah Grossman discovered that Adobe Flash Player could be clickjacked. It also allowed the hacker to gain access to the computer without any prior knowledge to the user. 

The term "clickjacking" was coined by these two experts, which is a combination of the words "click" and "jacking". Similar attacks of this nature were reported soon after, which made the term relevant in other application security experts' minds. Previously the attacks were termed as "UI redressing" but then got reverted to clickjacking. 

Clickjacking does not refer to one single attack; it consists of a rather extended family of attack vectors and strategies, referred to as "UI redress attacks", as per the old terminology. These attacks can be divided into two sections, based on the utilization of shrouded content. These shrouded attacks are one of the most popular. Integrating pages in invisible iframes is one of the most common strategies employed here. Some of the other types of clickjacking based on hidden content include,

Full Transparent Overlay

This is the method which is described in the instance mentioned above. A legitimate page also called a tool page, will be shrouded or overlaid over a structurally created suspicious webpage. The tool page is then set up on an invisible iframe and placed over the visible page by increasing the z-index value. 

The z-index specifies the order of stack of an element and is most commonly present in CSS. One of the most famous cases identified using a full transparent overlay was against the Adobe Flash plug-in settings. It tricked users into providing access to Flash animations and the system's primary camera and microphone. 

Cropping

The hacker will overlay only a specific set of controls from the transparent page to the target page to demonstrate this attack. It will mean hiding the buttons with invisible links ensuring that it executes a different behaviour than expected, and all of this depends on the aim of the attack. The attack pattern can also include hiding text labels with falsified instructions, changing the buttons with inaccurate commands. 

It can even involve hiding the entire page altogether with malicious and incorrect information, barring just one original button. Every one of these mentioned behaviours comes under the ambit of cropping. 

Disguised Overlay

Disguised Overlay was the first actionable instance of clickjacking. The hacker creates a 1x1 pixel iframe consisting of suspicious information and places it below the cursor. It successfully hides it from the user's view, and it will register the user on that suspicious page if you make any clicks using the cursor. 

Click Event Dropping

This method involves a legitimate page displayed in the foreground, causing it to hide the suspicious page behind it successfully. The hacker will then set up CSS pointer-events property at the peak to nil. It will cause all of the click events to drop right through the legitimate masked page. What's more, it will also register you directly to the page containing suspicious information. 

Increased Content Replacement

Blurred overlays are made use of to cover the target controls. This action is only carried out for a fraction of a second or momentarily until the user clicks on it, and once done, it is replaced by pronto. The attack's nature involves the hacker predicting the location of the user's click accurately, and it does not require any prior computer usage habits. It will sound tricky, but it is pretty straightforward. 

Attackers can additionally insert overlays without exploiting clickjacking vulnerabilities. They have a host of options to trick users into clicking on the controls that they want them to. Some of these tricks involve:

Scrolling

The hacker will partially scroll a legitimate web element or a dialogue box out from the screen enabling the user only to see a few controls. For instance, a dialogue box mentioning a warning can be scrolled off so that only the Cancel and OK buttons are visible to the user. The hacker will place a very safe prompt text which will mention that you must click on this button to proceed further and not brush it off as a warning. 

Repositioning

This kind of attack will require the hacker to move a genuine dialogue box under the cursor. At the same time, the user is distracted by some other items that look pretty harmless. The hacker also uses these items to distract the user from the main thing through repositioning purposefully. 

If this operation works, the user will then automatically click on the substituted control before realizing that something has changed on the page. This operation is relatively similar to the rapid content replacement process, and the hacker will shift the dialogue back to its original spot to avoid discernment.

Drag and Drop

While many clickjacking attacks focus their attention on click interception, drag and drop vulnerabilities can be programmed to trick the user into carrying out a series of activities. It can include completing web forms by dragging an invisible text into a hidden text box or by unmasking confidential personal information to the hacker. 

Other different forms of attacks

The user and web page elements interact dynamically, and it is possible through an amalgamation of DOM, JavaScript, and CSS. These tools offer several options to attackers to trick users into performing various unwanted activities. This is because clickjacking attacks tend to exploit the user's trust by using controls and other misleading information. These are hard to detect at times, and new attacks are a possibility at every step.

A sizable number of clickjacking attacks involve setting up a target web page into an iframe at some point in time. Therefore, all the prevention methods will not allow framing. Traditional legacy solutions make use of client-side scripts to break pages out of these frames. Still, a modern approach and a secure one mainly rely on setting an HTTP security header to specify specific framing measures. Some of these measures are listed as follows:-

Framebreaking or Framebusting

Before support for new HTTP headers became popular, many website developers had to deploy a specialized framekiller or a framebuster script to stop their pages from being "iframed". One of the first framekilling scripts was top. It was to ensure that this was the existing page. But these scripts could be blocked easily from the outer frame or can be bypassed. 

Thus, a more distinctive and comprehensive solution to this was developed. Still, there were several ways to bypass the most detailed framekillers, and these scripts must be used in instances when you want to provide fundamental security to legacy browsers. This approach officially advocated by OWASP is to mask the HTML document body and only make it visible after appropriate verification that the page is not "iframed".

X-Frame-Options

One of the best solutions to make use of at present is the X-Frame-Options (XFO). It is an HTTP response header used for server responses. It was introduced for Internet Explorer 8 by Microsoft and was then formalized in RFC 7034. The XFO header is used to identify whether a page can be integrated into an iframe, embed or object element. XFO supports three directives. 

  • Contradict to block possible framing attempts
  • Use same-origin elements to allow framing by pages at the same source.
  • Use allow-from element to allow framing by pages from designated URLs

But the allow-from element is not supported by many browsers, which includes Safari and Chrome. Thus, if you want to identify sources, you need to use CSP or Content Security Policy. For protection against anti-framing, you would need to add X-Frame-Options: deny OR X-Frame-Options: same-origin in your server headers.

Content-Security-Policy with frame-ancestors

The CSP HTTP header was created to prevent XSS (Cross-Site Scripting) and other attacks. Additionally, it provides a frame-ancestors directive for itemizing sources allowed to integrate a page in the iframe. It can even integrate a page in the object, embed, or applet elements.

You can designate any number of sources and other source values which are supported. This includes host IPs or even addresses, scheme types, 'self' to itemize the origin of the current document, and use 'none' to stop allowing the embedding procedures. 

All of these options give users a whole lot of flexibility for source definition in complex deployment scenarios. For basic security, 'self' and 'none' will prove to be sufficient enough. The former is equivalent to the same-origin directive of XFO, while the latter is similar to 'deny' is XFO.

While it may not give you a complete guarantee regarding clickjacking, the XFO HTTP header is a universal way of elevating general website flexibility. It eliminates not just the basic clickjacking attempts but also a host of other weak points. The CSP directive should also provide you with protection equivalent to XFO, but the latter is widely accepted and recommended as well, even though it is deprecated now. 

If both headers are present, the CSP will point towards the frame-ancestors primary importance, and XFO will be rejected. But the operation in some of the older browsers like Chrome 40 and Firefox 35 is the opposite. Whatever measures we choose, you can use Netsparker to check the websites you are accessing for XFO and CSP headers. You can even ensure that all of the security policies are in place and are consistent across all the web pages.  

Barring the server and client-side anti-framing schemes, users stay secure from clickjacking due to security measures built into today's browsers. A web page rendering involves multi-layer checks ensuring that the interface behaves as per the user expectation. The process also includes anti-clickjacking algorithms, which will work against repositioning and scrolling attacks described above. The browsers will also receive options to block unnecessary pop-ups and other suspicious web page behaviours and notify the user that malicious activity occurs. 

XFO was not a permanent solution to the problem of clickjacking. It was universally adopted by browser vendors and CSP's frame-ancestors directive. This directive provides a more flexible solution to the same approach. Both headers from XFO and CSP can provide security against the threat of framing overlays and other prevalent clickjacking attacks. Frame-ancestors may observe a universal acceptance in the future to prevent rampant usage of iframes by hackers. 

It is also important to understand that clickjacking is not just about iframes; it is also about breaking the user's trust and misleading them about what they see in their browsers. It is important to note that most browsing traffic comes from mobile browsers compared to the web. Therefore, the potential for creating falsified user interfaces is expansive, and only protecting web browsers is not enough.

Clickjacking has many nuances, and hackers take a lot of effort in stealing information from the users. You as a user must understand what clickjacking involves and how you can secure yourself from these threats. This applies to you if you scroll through unsecured websites for a large amount of time. 

It applies to you if you want to secure your system against these threats because overlooking this problem will result in consequences that will be catastrophic for you. If you are an individual user or working in an organization, then you need to get involved in stopping this from affecting your system proactively, and that is something to think about.  

Antoniy Yushkevych

Master of word when it comes to technology, internet and privacy. I'm also your usual guy that always aims for the best result and takes a skateboard to work. If you need me, you will find me at the office's Counter-Strike championships on Fridays or at a.yushkevych@monovm.com