What Is Clickjacking?

“Click what now“? Clickjacking is a generally misunderstood security vulnerability that is often difficult to explain and understand. The attack itself has been around for some time now; the term comes from a portmanteau of the words “click” and “hijacking.” But what is clickjacking? How does clickjacking pose a risk? More importantly, how do you defend against clickjacking? Let us take a look.

Clickjacking generally refers to a type of attack in which a user is tricked into clicking on actionable content on a hidden website. This is usually done via an intermediary website. Consider the below image:

The victim visits the attacker’s website with the intent of communicating with the visible user interface, but unintentionally interacts with the secret tab. A hacker may use the hidden page to trick people into doing something they didn’t want to do by strategically placing hidden elements on the web page.

Now we understand the concepts. Let’s actually see what this might look like in the wild. We will be using clickjacker.io to demonstrate how a website (which offers no protection against Clickjacking) can be used.

The below image shows the website nmap.org being rendered in an IFRAME on the clickjacker.io website. To demonstrate the Proof of Concept. A “Click here” button is overlayed ontop of the website.

So now we understand what clickjacking is. What about clickjacking prevention? In order to resolve the issue, we must first understand what is causing it. Essentially what’s happening here is the nmap.org website is allowing a third-party website to embed it into an IFRAME, thus making clickjacking possible. Now nmap.org could resolve this issue fairly easily.

THE SOLUTION:

Disallowing clickjacking can be done through the appropriate HTTP Security Headers. These headers will instruct the browser not to render the website in an IFRAME.

We can either use the ‘Content-Security-Policy‘ security header, or ‘X-Frame-Options‘.

Below we can see various configurations of the Content-Security-Policy header. Either of them will stop this attack from occurring in most cases.

Content-Security-Policy:

1. Content-Security-Policy: frame-ancestors ‘none’ – Set this if you want to disallow every domain from embedding your site in an Iframe.
2. Content-Security-Policy: frame-ancestors ‘self’ – Set this if you want to disallow every domain from embedding your site except the site itself (Hence ‘self’).
3. Content-Security-Policy: frame-ancestors uri – Set this if you want to allow a specifc uri to embed your site in an Iframe and dissallow all the others.

X-FRAME-OPTIONS

Alternatively, the X-Frame-Options header can be used.

1. X-Frame-Options: DENY – The page is not allowed to be displayed in a frame, regardless of what origin requested it.
2. X-Frame-Options: SAMEORIGIN – The page can only be displayed in a frame from the same origin as the website.

Let’s take a look at a target site which does implement an adequate framing policy, below you will see our breaches database stopping the third party site from rendering it in an IFRAME.

If we take a peak at the RAW HTTP HEADERS, we can see that breaches.sencode.co.uk implements the X-Frame-Options security header.

{
“HTTP/1.1”: “200 OK”,
“server”: “nginx/1.14.0 (Ubuntu)”,
“date”: “Sun, 07 Mar 2021 20:51:38 GMT”,
“content-type”: “text/html; charset=utf-8”,
“transfer-encoding”: “chunked”,
“connection”: “close”,
“referrer-policy”: “same-origin”,
“x-frame-options”: “SAMEORIGIN”,
“strict-transport-security”: “max-age=86400”
}

The best way to check your website is safe against clickjacking is with a web-app penetration test.