Many of the external network and web application penetration tests that we perform list ‘clickjacking’ as a vulnerability. We find that many website developers, as well as many users, do not fully understand what clickjacking is. While clickjacking is not exploitable to gain system access on its own, this web configuration vulnerability can be used to gather valid credentials that can lead to system access when paired with a social engineering attack such as phishing. Clickjacking falls under the A6 – Security Misconfiguration item in OWASP’s 2017 Top 10 list.
A LOOK AT HOW IT WORKS
Clickjacking uses a genuine webpage, usually a login page, to trick users into entering private information such as credentials. To show how this works, we created a sample login page for a great little app called Not a Secure Site.
As the page does not implement clickjacking protections, an attacker can quickly and easily clone the page by placing it within an HTML iframe on their own website. By overlaying their own username, password, and sign in button elements on a layer above the iframe, the attacker can capture any credentials the user believes they are entering into the original login form. The example below shows how the attacker’s cloned page might look. Can you tell the difference between the real site and this malicious site?
Without inspecting the source code of the malicious page, the content of the page appears identical to the legitimate one. Now, let’s highlight the overlaid text fields and button fields in blue so we can see where the magic takes place:
Those fields are in a layer of HTML that is physically sitting on top of the iframe containing the Not a Secure Site’s log in page. When an unsuspecting user enters their credentials on this page, they are entering them in the attacker’s text fields and clicking the attacker’s button.Let’s add a border around the iframe on the attacker’s website:
Here we can clearly see where the attacker has embedded Not a Secure Site’s log in page into the malicious site.Using Burp Intercept, we can watch the HTTP Request. For this example, I just set the attacker’s form to POST to the Raxis website. In the intercepted request below, we can see that the user’s credentials entered into the form are being sent to the attacker’s site instead of to Not a Secure Site.
This is all very clever, but it doesn’t mean a thing if a user never enters credentials. This type of attack must be used as part of a larger attack, which is generally a phishing attack that encourages the target to click on a URL in an email.The HTML code on the malicious page can be remarkably simple. The attacker needs only to create and properly position text fields and a button on the page, and the iframe does the rest!
In more advanced clickjacking attacks, an attacker can log your credentials as you type them, capturing your username and password before you even submit the form.
WHAT WEB DEVELOPERS CAN DO TO PROTECT THEIR SITES
So, what makes this webpage vulnerable and what could the website’s developer do differently to fix it? It all comes down to preventing the page from being embedded in the iframe. Modern browsers look for the X-Frame-Options header to determine when an external site is permitted to be presented in an iframe. Looking at the HTTP response for Not a Secure Site’s log in page, we see that the site does not set the X-Frame-Options header, which defaults to allowing any site to be embedded in an iframe.
The X-Frame-Options header can be set dynamically in server-side code or configured on a global level through the web server or proxy configuration. The X-Frame-Options header allows three possible values:
- ALLOW-FROM uri
If the website never needs to be embedded in an iframe, the developer should use the DENY value to block all iframes. Here’s what the attacker’s website looks like when Not a Secure Site has set the X-Frame-Options response header for the entire website to DENY. The header prevents the login page from rendering within the iframe.
WHAT USERS CAN DO TO PROTECT THEMSELVES
Clickjacking recommendations are often focused on what web developers and website administrators can do to protect users, but what can you as a user?Keep in mind that the attacker has to trick you into using their website. Whether they do this through an email, a flyer, a poster on a wall, or casually mentioning it in a conversation, it’s always a good idea to verify that the link you are using is legitimate. If you’re at work, check with your IT department; if you’re a user of a consumer site, go to the genuine site and use the contact form or the phone number there to verify the link.Remember that links can be masked to look like something else. Hover over links in emails and webpages to see what URL they truly point to. Look at URLs carefully to see if they are legitimate. Attackers will often buy domain names that look a lot like the true website’s domain in the hopes that their targets will not look closely.See our recent phishing blog post to learn more about protecting yourself from phishing attacks.