What is clickjacking and what can you do to prevent it?

Clickjacking is an online attack that tricks a victim into clicking something other than what they intended without realizing it. Clickjacking is also referred to as a user interface redress attack (UI redress attack). The classic clickjacking attack “redresses” the user interface that’s visible to the victim by embedding a malicious website into an invisible iframe on top of the original webpage.

The victim has no visual cues that there is an invisible iframe on top of the page they actually see. The invisible page contains clickable elements that align with the actual buttons on the visible page underneath. Hence, when a victim clicks the ‘Download pdf’ button, for example, they’re actually clicking an invisible element that downloads a malicious script that their browser then executes.

An iframe is basically a frame within a frame. Iframes enable you to embed content from other sources (websites) onto your webpages. When you visit a website that has an embedded Youtube video displayed, for example, that Youtube video lives in an iframe.

As is the case with many online attacks, clickjacking attacks typically use some form of social engineering to direct the targets to the compromised/malicious site. This can be an email, a text message, a Facebook post, etc.

It’s not just mouse clicks either. Using a combination of stylesheets, text boxes, and iframes, an attacker could fool an unsuspecting user into thinking they’re typing in their password on their online banking site, when in fact, they’re typing it into a site controlled by the attacker.

Two security researchers, Jeremiah Grossman and Robert Hansen, coined the term ‘clickjacking’ after discovering that Adobe’s Flash player was vulnerable to clickjacking in 2008.

Unfortunately, the threat is still ongoing. In late 2023, for example, Mozilla issued security updates after clickjacking vulnerabilities were discovered in Firefox 120.

There are many different variations of clickjacking attacks and because of that, the expression “UI redress attack” is more common today. It’s an umbrella term that includes all variations.

Working example of clickjacking

1. An attacker crafts a legitimate-looking website and embeds a malicious website inside an iframe. The iframe is invisible, so the malicious site isn’t visible and the victim only sees the legitimate-looking site.
2. Invisible elements on the embedded malicious site line up with clickable elements on the legitimate-looking, visible page. The invisible elements trigger undesirable actions, such as downloading a malicious script, when clicked.
3. The attacker uses some form of social engineering to trick the target into visiting the malicious website and clicking the malicious link. This could be a link to a fake contest that they’ve won or to an enticing celebrity photo, for example.
4. Once the target visits the site and clicks the link, the target’s browser executes the malicious script and bad things happen.

The embedded site can also be a legitimate, yet vulnerable (to clickjacking) website. Let’s take the same example as above, but make the embedded, invisible site amazon.com. In this example, when the victim clicks the link or the button to say, claim their prize, or view the photo, they actually make an expensive purchase on Amazon. Granted, for this example to work, the victim needs to be logged in to their Amazon account and have one-click purchases enabled. But you get the idea.

It could also be the victim’s online banking website in the invisible iframe. The fake button could in fact be a confirmation to transfer funds to the attacker. If the victim is logged in to their banking site, the funds are transferred to the attacker (or to an entity controlled by the attacker).

This also highlights the fact that it is both website users and website administrators that need to take measures to mitigate such attacks. Any legitimate website that can be embedded in an iframe is vulnerable to being used in a clickjacking or UI redress attack.

We’ll look at how users and administrators can protect themselves further below. But first, let’s take a look at different UI redress attacks. They’re all basically variations on the theme of the classic clickjacking attack.

Clickjacking attack examples

Classic

We explained the classic attack above. It consists of crafting a legitimate-looking website and embedding a malicious or legitimate (and vulnerable) website in an invisible iframe. The attacker then tricks the victim (using social engineering) into clicking the malicious or legitimate but undesirable element. A legitimate but undesirable element would be something like Amazon’s 1-click purchase buttons to make an unwanted purchase. Or it could be a malicious element that downloads a nasty script to your browser. In either case, the victim believes they’re claiming their prize or opening an enticing photo on the legitimate-looking and visible website.

Likejacking

An extremely prevalent form of UI redress attack is likejacking: hijacking Facebook likes. Likejacking works similarly to the classic clickjacking attack. But it tricks Facebook users into “liking” things they never intended to. The attacker’s Facebook page is embedded in the invisible iframe. Hence, the user doesn’t realize they’re actually clicking the attacker’s invisible “Like” button.

A known occurrence of this attack happened in Italy, in 2011. In 2015, a journalist from the Canadian Broadcasting Corporation discovered he had “liked” the country’s Conservative Party. You can check whether you’ve been inadvertently “liking” things by navigating to the activity log in Facebook’s settings, and clicking on “Pages, page likes and interests.”

Cursorjacking

Cursorjacking consists of changing the location of the cursor from where the victim perceives it to be. A typical cursorjacking attack replaces the actual cursor with a fake one, using an image, and offsets it from the location of the real cursor. With clever positioning of elements, the attacker can trick the victim into clicking elements they never intended to click.

When the victim clicks an intended element with the fake cursor, the real cursor, which is offset from the fake one, actually clicks a malicious element. The real cursor may still remain visible in a cursorjacking attack. But efforts are made to focus the victim’s attention on the fake one.

Cookiejacking

Cookiejacking is a UI redress attack that steals the victim’s cookies. Once the attacker obtains the cookies, they can read the information it contains and use it to impersonate the victim. This is typically achieved by tricking the victim into dragging and dropping an element on the page. But what they’re actually doing is selecting the contents of their cookies on the embedded invisible page and handing that over to the attacker.

Filejacking

In a filejacking attack, the attacker exploits web browsers’ ability to navigate through the computer’s file system. An example would be when you upload a photo to social media. A file browser window appears and you can navigate your file system. In a filejacking attack, clicking the ‘Browse Files’ button (or whatever your browser calls it) establishes an active file server, potentially giving the attacker access to your entire file system.

How to prevent clickjacking attacks?

The way to protect against clickjacking attacks depends on which end of the attack you’re on. Client-side defenses are different from server-side defenses, and both are equally important.

Client-side

1. Use a browser that supports the Intersection Observer API

The Intersection Observer API can track the “visibility” of target elements on a web page. This API enables the browser to detect when a framed window is being hidden.

The following desktop browsers support the API at this time:

• Google Chrome 58 and above
• Mozilla Firefox 55 and above
• Microsoft Edge 16 and above
• Opera 45 and above

On mobile, there are so many browsers available on both Apple’s App Store and on Google’s Play Store that listing them all is close to impossible. However, the default browsers on both iOS and Android do support the Intersection Observer API, so that’s good news.

• iOS Safari from iOS version 12.2 and above
• Chrome for Android 51 and above

2. Use a browser add-on

Several browser add-ons can provide some protection against clickjacking attacks.

Some popular choices are:

• NoScript: The NoScript browser add-on prevents users from clicking on invisible or “redressed” web page elements. NoScript is free but is only supported by Mozilla Firefox.
• NoClickjack: The NoClickjack browser add-on is supported by Google Chrome, Mozilla Firefox, Microsoft Edge, and Opera. The add-on forces all frames on a webpage to be visible.

Server-side

On the server-side, the way to protect against clickjacking is to add the relevant directives to your website’s HTTP headers.

1. X-Frame-Options directive

Introduced by Microsoft in the 2009 edition of Internet Explorer, the HTTP header X-Frame-Options provided partial protection against clickjacking. Most major browsers today support the X-Frame-Options directive (Safari, Firefox, Chrome, and Opera). Once set by the website administrator, the header states its framing policy. The options are:

• DENY: Disallows all framing
• ALLOW-FROM origin: Disallows framing from external sites
• SAMEORIGIN: Only allows framing form the specified site(s)

The X-Frame Options header was never an official internet standard and has been supplanted by the frame-ancestors policy. Despite that fact, many websites still use X-Frame-Options today.

2. Frame-ancestors directive

The frame-ancestors directive of Content Security Policy (CSP) can control (by allowing or disallowing) embedding of content by potentially malicious pages using iframe, object, etc. CSP is an HTTP response header that enables you to determine which dynamic resources are allowed to load based on the source of the request.

As mentioned above, the frame-ancestors directive replaces and supplants the X-Frame-Options directive. If a page is served with both headers, the web browser should privilege the frame-ancestors policy. However, some browsers may disregard this requirement.

How to add the frame-ancestors directive to your website(s)

We’re going to provide instructions on how to enable the frame-ancestors directive on your website in both Apache and Nginx.

Apache

1. We first need to enable mod_headers.

sudo a2enmod headers

2. Then we need to restart apache

sudo service apache2 restart

3. We then need to edit either httpd.conf or apache.conf, based on your installation to add the frame-ancestors directive.

Deny from all sources

Header set Content-Security-Policy "frame-ancestors 'none';"

Allow self but deny all other sources

Header set Content-Security-Policy "frame-ancestors 'self';"

Allow from specific domains

Header set Content-Security-Policy "frame-ancestors example1.com example2.com example3.com;"

Allow from self and specified domains

Header set Content-Security-Policy "frame-ancestors 'self' example1.com example2.com example3.com;"

Remember to restart Apache after making changes

sudo service apache2 restart

Nginx

In Nginx, you need to edit your site’s corresponding configuration file and add the frame-ancestors directive under the ‘server’ block.

Deny from all sources

add_header set Content-Security-Policy "frame-ancestors 'none';"

Allow self but deny all other sources

add_header set Content-Security-Policy "frame-ancestors 'self';"

Allow from specific domains

add_header set Content-Security-Policy "frame-ancestors example1.com example2.com example3.com;"

Allow from self and specified domains

add_header set Content-Security-Policy "frame-ancestors 'self' example1.com example2.com example3.com;"

Remember to restart Nginx after making changes.

sudo service nginx restart

Conclusion

So there you have it. Clickjacking is a pretty nasty attack. Thankfully website administrators have a defense, as do visitors to the site. Nothing is 100%, however. So remain vigilant.

Here’s some additional common-sense advice, taken from my What is Trojan Horse malware and how to avoid it article, that may help you to defend yourself on the client side.

• Never click on pop-ups. You never know where they’ll take you next.
• If your browser displays a warning about a website you are trying to access you should pay attention and get the information you need elsewhere.
• Don’t click links (URLs) in emails unless you know exactly who sent the URL and where it links to. And even then, inspect the link carefully. Is it an HTTP or an HTTPS link? Most legitimate sites use HTTPS today. Does the link contain spelling errors (gooogle instead of google)? If you can get to the destination without using the link, do that instead.