What is Clickjacking & How to Prevent Attacks

Clickjacking is a type of cyberattack in which an attacker tries to get their victim to interact with a transparent (and thus invisible) user interface that has been overlaid on top of a legitimate user interface. Clickjacking can technically occur anywhere there is a graphical user interface, however it is most commonly used as an attempt to hijack web pages.

Clickjacking can be used in order to harvest sensitive information from victims (such as website credentials), cause victims to download malware, trigger the financial transactions or redirect victims to alternate websites. Defences against clickjacking are currently imperfect, but there exist steps that both website owners and website users can take to enhance protection. It is important to note that without the proper protections, any web application is potentially vulnerable to clickjacking, and does not require a specific clickjacking vulnerability.

What is Clickjacking?

Clickjacking is something of a slang term. The formal industry term for clickjacking is user interface (UI) redressing. To an industry insider this term actually makes more sense because modern clickjacking doesn’t actually “hijack” your cursor in any way, it just overlays something invisible on an area of the screen you are likely to click on with something invisible that you would not otherwise click on.

Clickjacking is a malicious twist on a fairly old programming trick: get someone to click on something other than what they think they’re clicking on. If you’ve played video games from the 90s you might have encountered it in the form of triggers for secret doors or similar hidden user interface elements. While a fun addition to a video game, in nearly any other context, clickjacking is a bad thing.

Modern clickjacking attacks make use of the HTML frames functionality, more commonly known as iframes. Iframes give developers the ability to display one webpage within another, something you probably encounter every day and never think about. Iframes are commonly used, for example, to embed tweets, maps, or even shipping estimates into a website.

This flexibility makes iframes extremely useful to developers. Using iframes, website developers can embed functionality into their websites that they themselves did not develop. Every company is not going to develop their own payment processor, mapping software, logistics software, etc. and then host it from their own domain. Iframes make it possible to build more modular websites, with different aspects of functionality provided by different vendors.

Clickjacking overlays hidden, transparent controls over a known website’s iframe. When you think you’re clicking on some element of the embedded website (for example, to click “submit” on a form), you actually end up interacting with the malicious, transparently overlaid control. A clever attacker will pass the click through to the underlying iframe, or use other means to achieve the same effect, meaning their victims might never know that a clickjacking attack has occurred.

By this point, if you aren’t a website designer or information security effort you’re probably thinking that clickjacking sounds like a lot of work. Do attackers really need to trick victims into clicking on things? Can’t they just use their programming skills to click on the thing themselves? The truth is that no, attackers don’t actually need you to click on most things. What they typically need from you is information, which is why UI redressing is a much better term than clickjacking, even though “clickjacking” is far more common.

For many – if not most – websites, actual human interaction is not required. Any computer science student should know enough after their first year of post-secondary programming classes to be able to write an application that automatically submits information to popular websites. Where clickjacking comes in is that attackers need information that only humans possess (such as credit card numbers or one-time passwords from multi-factor authentication) in order to complete their attack. Clickjacking is often how they get that information.

Types of Clickjacking Attacks

Clickjacking can be broken into multiple different types of attack, depending on the goal of the attack.
Cursorjacking is one of the original versions of clickjacking, and was in use before transparent overlay attacks were a thing. Cursorjacking relied on actually moving a user’s mouse cursor to a different a location on the UI. The user would think they were clicking on “submit”, but the cursor had actually been teleported off-screen somewhere to click a button that wasn’t drawn on the part of the screen the user could see, then moved back.

Cursorjacking is no longer a real threat, as it relies on technologies and web browser versions that are many years out of date, and was often used with older technologies, such as Flash. Iframe clickjacking has replaced it.

Likejacking is probably the simplest form of clickjacking. When users go to “like” a social media post (or similar feedback mechanism), those clicks are used to cause the victim to “like” one or more other posts that they did not intend.

Data harvesting is a technique in which information entered by the victim into a target website is captured, then used elsewhere. This could take the form of overlaying a transparent form field on top of a form field you think you’re clicking on, then passing that information both to the website in the iframe and to an attacker’s script at the same time.

Multistep clickjacking is where multiple interactions are required in order to accomplish the attacker’s goal. The most common example is getting someone to buy something that they didn’t intend. This might be as simple as adding an item into someone’s shopping cart and getting them to buy it. The clickjacking becomes multistep when the attacker has to do something else in order to accomplish their goal.

Let’s think about a simple “adding an item to your online shopping cart” clickjacking attack. From a programming standpoint, adding an item into a cart using clickjacking is as simple as likejacking: you go to add a coffee cup to your cart, and the clickjacking script adds a t-shirt. From the attacker’s point of view, however, this presents a problem, because when you go to check out, you might notice the t-shirt in your cart.

Attackers can try to solve this in a few different ways. They can try to inject the item at the very last second, right as you are clicking “purchase”, and hope it is missed. Alternately, they might try to manipulate what the victim sees from the underlying iframe to hide the purchase. Either way, the more steps required, the more difficult the clickjacking is for attackers to accomplish.

Cross-Site Scripting clickjacking is probably the most powerful form of clickjacking attack. Cross Site Scripting (XSS) attacks are when one website allows scripts from another website to be executed against it. XSS attacks are often combined with data harvesting in order to avoid the complexity of multistep clickjacking, but do not explicitly require it.

XSS clickjacking evolved as a way to work around common website and web browser defences. Modern websites use HTTPS, logins, and other techniques in order to require you to actually go to the website and establish a session with that website in order to interact with it. Once those sessions are established, if an XSS vulnerability exists on the target website, then getting a victim to click on a transparent UI element may be all the interaction required to bypass web browser defences and allow an attacker’s script to run against the target website, using the victim’s established session.

So if XSS clickjacking is the ultimate boogeyman of the clickjacking techniques, how does it actually work?

Clickjacking Example

A clickjacking attack starts with the victim being where they aren’t supposed to be. In order for a website (such as Amazon) to be in an iframe in the first place, the victim needs to be visiting a website that has embedded the target in an iframe. Phishing and links on malicious websites are common way for attackers to get victims to navigate to such a site.

Let’s say that an attacker has found an XSS vulnerability on Amazon’s website, and puts a link to a malicious website in a review blog. You, looking for reviews on a product mentioned in the block, click on a link, and it takes you to an attacker’s webpage where Amazon’s webpage is embedded in an iframe that takes up the whole browser window, so it looks normal.

You log in, enter your one-time-password, and proceed to start shopping. By doing this, however, you have now established a session with Amazon’s website. The attacker is now free to execute scripts against Amazon’s website using your established session, and in addition to that swanky new monitor you set out to buy, a second order was placed in your name, and coming off of your credit card for 100 teddy bears.

If you are looking for code examples of clickjacking, we recommend looking through Github.

How to Prevent Clickjacking

Techniques to prevent clickjacking largely rely on either restricting the ability of certain websites to be put into iframes at all, or making it really obvious that they have been put in an iframe. Clickjacking defences can broadly be broken down into two categories: client-side, and provider-side.

Client-side clickjacking protections usually come in the form of either browser features or browser extensions. These protections can be heavy-handed, such as NoScript’s complete disabling of JavaScript, or they can be more subtle, such as making all frames clearly visible, regardless of the website designer’s use of transparency effects.

Some client-side defences attempt to prevent clicking on invisible UI elements, or only on invisible iframes. This may take the form of only allowing interaction with the top window or frame. More advanced clickjacking protections attempt to intercept potential clickjacking attacks and alert the user.

Provider-side defences largely focus on adding code to a website that tells web browsers not to allow types of interaction that enable clickjacking. These approaches are still technically client-side, in that they require the web browser in question to honour the settings embedded in the website’s code, but should work on modern web browsers (and are a good example of why it’s important to keep your web browser up to date).

The first provider-side clickjacking defence is the X-Frame-Options HTTP header. X-Frame Options has three different possible settings:

• DENY – Do not allow this website to be displayed within an iframe
• SAMEORIGIN – only allow this website to be displayed within an iframe from the same domain
• ALLOW-FROM URI – only allow this website to be displayed within an iframe from a specific URI

X-Frame-Options, however, relies on the X-Frame-Options setting to be set on all individual web pages within a given website. Content Security Policy (CSP) is a similar approach that can be implemented at the web server level as a return header. This makes it more difficult for it to be missed, however, CSP is both versatile and powerful: it must be used with caution and tested thoroughly.

It is the CSP frame-ancestor settings specifically which are useful against clickjacking. The three settings are largely the same as the X-Frame-Options settings:

• Content-Security-Policy: frame-ancestors ‘none’
• Content-Security-Policy: frame-ancestors ‘self’
• Content-Security-Policy: frame-ancestors URI

Website providers should use both X-Frame-Options and CSP frame-ancestor settings. Not all web browsers support both, and some browser extensions can bypass one or both of these approaches.

For more information on how to defend against clickjacking, check out the OWASP clickjacking defense cheat sheet at https://www.owasp.org/index.php/Clickjacking_Defense_Cheat_Sheet.

Conclusion

Clickjacking is a very real threat that is being actively exploited by attackers today. New ways to bypass defences are constantly being researched by attackers (for example, attackers may be able to use the HTML5 iframe sandbox attribute), and new defences are regularly being added. Constant vigilance by both website providers and end users is required to ensure that we don’t become the next victim.