Take a look at our newest, updated blog on clickjacking at https://raxis.com/blog/clickjacking-explained/.

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:

• DENY
• SAMEORIGIN
• 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.

The SAMEORIGIN value can be set if the webpage needs to be within an iframe on its own site. The ALLOW-FROM uri value is not recommended because it’s not supported by all browsers.While the X-Frame-Options header is the best defense against clickjacking attacks, the Content-Security-Policy directive can use the frame-ancestors property to restrict which domains are allowed to place the website in a frame, though frame-ancestors is not yet supported in all major browsers.OWASP has a great Clickjacking Defense Cheat Sheet explaining these options in detail, as well as explaining old methods that will not work well and are not advised. The OWASP Secure Headers Project is another great tool that you might want to check out.Raxis offers several penetration tests that alert customers to websites that are vulnerable to clickjacking. Check out our Web Application Penetration Testing service to get a start. If a full penetration test is not within your company’s needs or budget, take a look at our Baseline Security Assessment option, which also highlights clickjacking vulnerabilities.It’s important to note that some phishing attacks will copy webpage code, instead of embedding the page in an iframe, to achieve the same results. Depending on the webpage, this can be complicated and may require an advanced knowledge of HTML, JavaScript, and CSS. When an attacker is able to produce a convincing clone of a website without using an iframe, any form of clickjacking protection, including X-Frame-Options, cannot prevent this form of attack.

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.

Want to learn more? Take a look at the next part of our Web Attacks Series.