Blog: How-Tos

Clickjacking explained, in detail

Minh-dat Lam 17 Oct 2013

1. Introduction

This blog post is an aide to improving the security awareness of clickjacking.

The following areas will be addressed:

  • Understanding the key principles of clickjacking.
  • Understanding the business risk and impact of clickjacking.
  • Understanding the technical aspect and testing methodology for clickjacking.
  • Understanding the remedial action for clickjacking.

These essential areas should aid technical and non-technical parties in understanding the consequences of clickjacking and how they can prevent web applications from being vulnerable.

2. Understanding the Key Principals of Clickjacking

Clickjacking was first identified in 2008 by Robert Hansen Jeremiah Grossman who were looking for a way in which to circumvent anti-Cross Site Request Forgery (CSRF) nonces and the browser’s same origin policy.

In its simplest form, clickjacking is merely attacking users’ interactive “clicks” via transparent or concealed layers. These layers can be placed over likely attack vectors such as buttons and hyperlinks, potentially deceiving users into interacting with an attacker’s malicious code.

3. Understanding the Business Risks and Impact of Clickjacking

The potential risks exposed by clickjacking and its inherent impact render it a medium risk issue in most sensitive applications, such as financial or sensitive data handling apps. The reason why it is a medium risk and not a high risk issue is down to the delivery method of attack and its execution vectors. This vulnerability requires user interaction and an element of social engineering as victims (generally the more technologically naive) have to voluntarily interact with the malicious page.

There are other factors to account for, such as the application environment and its exposure to specific user types. In addition, the type of data that can be “obtained” or “manipulated” need to be considered when rating the risk as it will be specific to the targeted business.

The overall risk may only be a medium rating; however, the impact is high. This vulnerability can be linked to a multitude of attacks including keylogging and stealing user credentials.

An example of an attack on a financial application could consist of sending out emails to authenticated users of the application. This would require either some amount of inside knowledge or the use of social engineering techniques to target specific users. Alternatively, mass emails could be sent out in the hope one user logged in to the application responds. The email would contain an “interesting” link which directs the victim to a landing page displaying an advert.

 

On the landing page is a “skip this ad” link that has a transparent iframe located over it (placed by the attacker). When the victim then clicks on the link, they will interact with the attacker’s malicious code and thus send a static request to transfer £1000 from the victim’s current account to the attacker’s listed account.

Further examples of clickjacking attacks can be seen occurring in the past on social media sites where victims are enticed into clicking links which spam their contacts as reported by the BBC News – http://www.bbc.co.uk/news/10224434.

4. Understanding the Technical Aspect and Testing Methodology for Clickacking

To begin with, specific attack pages within the application need to be enumerated. What is meant by this is that certain web pages may post data that an attacker would want to manipulate. As stated above, this interesting page could be a “transfer funds” form that contains the originating and destination account, along with the transfer amount.

Now you have your business risk for the application, you need to test that clickjacking is indeed possible. This can be quickly tested by loading the interesting web page within an iframe as shown below:

iframe-page

This was done using the following HTML code:

<pre lang="JavaScript" line="1">
<html>
<head>
<title>Pen Test Partners ClickJacking PoC</title>
</head>
Pen Test Partners ClickJacking PoC
<h2>Your Web Application Can be Mounted within an iFrame and is vulnerable to ClickJacking!</h2>
<iframe src="http://192.168.0.135/WackoPicko/guestbook.php" height="450" width="1000"></iframe>
</body>
</html>
</pre>

The above was a basic example to show a proof of concept; however, full attacks are much more technically advanced in nature and can be conducted, not just simple social engineering style attacks. A great blog post detailing this, specifically how to exploit clickjacking to obtain a shell on the victim’s machine, was written by OWASP’s New Zealand chapter and can be found on securityassessment.com.

5. Understanding the Remedial Action for Clickjacking

Clickjacking can be prevented using a host of client side browser plugins such as
• NoScript – http://noscript.net
• Web Protection Suite – http://www.comitari.com/Web_Protection_Suite
These plugins are recommended for daily browsing and can also protect users against additional client side attacks, such as XSS (Cross Site Scripting).
The above plugins are client side prevention techniques that should be taught to all application users; however, steps must also be taken from the developer’s end.

The following techniques can be used to aid in the prevention of clickjacking:

5.1. X-Frame-Options

The simplest of all the techniques that only requires a simple configuration setting; for example, this can be done within Apache using the following line:

<pre lang="JavaScript" line="1">Header always append X-Frame-Options DENY</pre>

5.2. FrameBusting JavaScript

This method utilizes JavaScript to “bust” iframes. This is done by checking if the current web page is the top web page (not within a frame) and if the web page is currently not the top page, then it becomes the top page.

The following example segment of code can be used to demonstrate this:

<pre lang="JavaScript" line="1">if (top.location.hostname != self.location.hostname){
top.location.href = self.location.href;
}</pre>

It should be noted that recent techniques have found to be able to bypass this clickjacking prevention technique as seen in the whitepaper by web application security researcher Collin Jackson – http://www.collinjackson.com/research/xssauditor.pdf.

5.3.Unique URL request

Similar to a CSRF nonce, this can be employed so attackers cannot deliver the attack URL easily.

5.4. CAPTCHAs

Similar to the way it prevents attackers from spamming a web form, this can be used as an additional layer of verification on each transaction.

5.5. Element Randomization

Generally it is possible to clickjack due to buttons and links being in a static area of the web page, allowing attackers to place invisible frames over them. A technique to prevent this from occurring is to randomize the links or buttons on load, thus preventing attackers from hard coding static iframes.

6. Reference