Hey Folks, in this tutorial we are going to be cover an interesting topic that you can pronounce as “Clickjacking” vulnerability. This vulnerability is often found in web applications that can be easily exploited and mitigated by attackers and developers. Simple 🙂 !! In this tutorial we will talk about both these things with a extremely good example.
Let’s start 🙂 !!
What is Clickjacking Attack ?
Clickjacking attack are also known as a “UI redress attack” that prompts a user to take malicious actions such as: stealing cookies, obtaining credentials, sensitive information and transfer money etc by clicking on an invisible or hidden button which are not intended to be done. For instance : Now we will take a small example to clear the whole scenario. As you can see, a user visits a website to grab free gifts and vouchers (which are often attacked by users to cheat), but despite their bad luck, as soon as they click on free “gift” button, the money is transferred to another user account without his knowledge.
Usually the attacker creates an invisible page or HTML element that the user cannot see due to using multiple layers with the help of the “z-index” CSS property or transparency and as soon as users click on the element of the visible web page then message is shown accordingly but the really happens something else that has no intention of doing by the user. Now we will consider this attack as some interesting examples.
Purchase Movie Tickets
As you can see we are using bWAPP vulnerable web application even you should configure it in your localhost machine to practice web application attacks, you can configure it from here. Look over the image below in which has some essential options for buying movie tickets by clicking on which we purchase the first ten movie tickets. That’s it normal process 🙂 !! Also a hyperlink is mentioned in the HINT message on which we will click to check the activity.
Iron Man 🙂 !! The web page offers us free movie tickets WOW 🙂 !! But it is completely the bait given by the attacker to take unwanted action by the users. Let’s see how we can identify whether this is a complete trick or not.
As you can see, after visiting the source code of the web page we get a useful information where the attacker has used an image to cover the iframe.
The image used by the attacker which you can see below after clicking on the link.
The forensic investigation is over and it is time to take the action that the attacker wants us to do. As you can clearly see that when the user clicks on the confirmation option to get the benefit of free ticket, so the charges are automatically deducted from the user’s account without his knowledge and it is occurs due to the invisibility of the web page behind.
Typically, this vulnerability arises due to allowing the “X-frame-options” facility in web applications and can simply be reduced by “DENY” this facility.
CSRF with Clickjacking
This will be the second attempt to change the password of the current user with the help of CSRF vulnerability. Look at the image below where we have created a phishing page that looks similar to the google search engine through which we can get unwanted action from users in two ways.
First : Add an iframe behind a visible webpage that has a transparency level of 100 percent.
Second : Change the action and add the exact parameter so that the user’s password is automatically changed after clicking on button as shown in the picture below. In our case we will take second scenario. but make sure the web application should be vulnerable to CSRF vulnerability.
Go back to the visible web page and as soon as the victim will try to find their problems on the google search engine then action will be perform that the attacker wanted.
Great 🙂 !! As you can see the user’s password has been changed without his knowledge. Similarly if the user is active in his account and the web application is vulnerable to CSRF vulnerability then the attack can take over the account with the help of both these vulnerabilities.
Using X-Frame-Options header will be the best solution for reduce the impact this vulnerability, but header should have these options.
- ALLOW-FROM URL