Clickjacking

In this chapter, we are going to learn about clickjacking vulnerabilities.

Type of vulnerability: Client-Side

Chances to find: Common; Clickjacking is part of “Insecure Design” ranked #4 in the “OWASP Top-10 Vulnerabilities“

TL;DR: A Clickjacking vulnerability enables an attacker to trick a victim into sending an HTTP request to a web application without the victim seeing that activity.

What is Clickjacking?

Clickjacking, also known as a “UI redress attack”, is when an attacker uses multiple transparent or opaque layers to trick a user into clicking on a button or link on another page when they were intending to click on the top level page. Thus, the attacker is “hijacking” clicks meant for their page and routing them to another page, most likely owned by another application, domain, or both. (src: OWASP)

Let’s have a look at an example. Let’s think of a retail website where you can buy any sort of good (e.g. a brand-new bicycle) from various sellers. An attacker, who is having an account on that platform could now try to sell more articles.

He goes ahead and creates his own website. On this webpage, he hosts an iPhone raffle, where a lucky user can win the latest model. On the very same website, he uses an iframe to load the retail website. Think of an iframe as a little window that shows website A while being on the attacker’s website B.

Now to the evil part. The attacker uses CSS (or cascading style sheets) to show the content of the iframe transparently. Hence, somebody who is visiting the attacker’s website has no idea that the retail website is loaded. However, every single click that can be made on the retail website is still available within the browser. Now, the attacker only needs to create a fake button that draws the victim’s attention to clicking it.

For easier understanding, let’s look at this image:

The website with the actual “PAY” button is the retail website. The website with the fake “CLAIM YOUR PRIZE” button is the attacker’s website. He now only needs to place the fake button over the actual one, hiding the retail website.

If a victim visits the attacker’s website, he sees that he can claim his prize and clicks the button. The browser however ends up sending an HTTP request to the retail website paying for the product the attacker chose.

Testing for Clickjacking!

If you want to get your hands dirty right now and want to search for Clickjacking vulnerabilities, we recommend you to check out Burp Suite’s Clickbandit. This free-to-use tool makes it as easy as possible to check if a potential website is vulnerable.

The impact of Clickjacking!

The impact is heavily depending on the application’s functionality and can range from no impact at all to a highly severe issue. Let’s investigate the reason for that with two more examples:

Think of a page that can get framed which has one button to show the current temperature of e.g. San Francisco. If you trick your victim into clicking that button, there is no impact at all.
Now think of a website that has a button to delete all your medical records that you have acquired over the years (with no rollback mechanism). Tricking a victim into clicking that could potentially have a severe effect on this person’s life if important medication information, etc. is lost.

How to prevent Clickjacking?

Clickjacking can be prevented via various different ways. While one of them should already do the trick, it’s always recommend to follow a defense-in-depth approach, meaning that multiple security controls should be applied. Let’s have a look:

The most obvious would be to prevent the framing of a website in the first place. Modern day browsers offer two ways to do that:
- You can either set the X-Frame-Options response header to DENY or SAMEORIGIN (more info here).
- Another option would be to rely on the frame-ancestors directive using a content-security-policy. You can either set the directive to frame-ancestors 'none'; or frame-ancestors 'self';.
Include a so-called “frame-buster” script which is an additional Javascript code included in your page that prevents framing. Click here for example scripts.
Alternatively, you can prevent the impact of clickjacking (not the framing itself) by using SameSite cookies. Make sure to set the strict or lax attribute on your session cookies. Doing that, the cookie is not sent to the web application if loaded within an iframe. Note: If your application allows impactful requests to be sent without authentication, then this method is not providing any additional security.

Find a more detailed overview by OWASP over here.

Additional resources:

Let’s have a look at a video example of a Clickjacking vulnerability:

Here is one more video, where are going to see how we can combine Clickjacking with a DOM-Based XSS vulnerability:

Following links are valuable to learn more about IDORs: