In a clickjacking attack, the user is tricked into interacting with a UI element that they do not see. The attacker designs a malicious page with carefully positioned visual elements. The user is lured into clicking on these elements but, in reality, unknowingly clicks on an element on a different page.

The term clickjacking was coined by Jeremiah Grossman and Robert Hansen (click + hijacking). They introduced it in their research on an Adobe Flash vulnerability. The technical term for a wider scope of such attacks is user interface redress (UI redress attack). There are varieties of clickjacking such as likejacking (hijacking Facebook likes) or cursorjacking. Clickjacking has been known to be possible since 2002 but is treated as a web application security issue only since 2008.

Clickjacking is an attack aimed both at a user and at another website or web application. The user is the direct victim and the website or web application is used as a tool. Defending against clickjacking means making sure that your website or web application cannot be used as a tool.

Clickjacking Examples

There are many clickjacking techniques. Here are some examples, how attackers may apply different techniques to trick the user:

  • The attacker creates an invisible iframe (transparent overlay) over the malicious page and loads the tool page into that overlay. The malicious page contains a visual element that lures the user into clicking. For example, it may be a graphic element that looks like a video player with a play button in the middle. The user clicks on the play symbol but due to the overlay, they click on a UI element on the tool page.
  • The attacker creates a 1×1 pixel iframe that moves with the mouse cursor. Due to its size and positioning, this frame is completely invisible (hidden under the cursor symbol tip). If the user clicks anywhere, they click on whatever is loaded and positioned in this 1×1 frame.
  • The attacker uses fragments of the tool page on the malicious page by cropping. For example, they create an iframe that contains the Submit button from the tool page.

You can find a full list of clickjacking techniques on the W3C (World Wide Web Consortium) security page.

Clickjacking Impact

Attackers may abuse clickjacking vulnerabilities for many different purposes:

  • To gain followers on social media and then, possibly, sell the social media account/page for mass marketing.
  • To gain email or RSS subscribers for the same purpose as social media followers.
  • To use the fact that the user is logged into their e-commerce account and have them buy products on behalf of the attacker.
  • To have the user unknowingly transfer funds to the attacker.
  • To have the user download malware (e.g. a trojan).

In general, clickjacking uses depend only on the attacker’s imagination and on finding a vulnerable tool page to use for that purpose.

Clickjacking Prevention

As a website or web application owner, you must make sure that your web assets cannot be used in a clickjacking attack. You may use several techniques for that purpose. You can also use several of them together to ensure full coverage. Here are the techniques in order of preference.

Content-Security-Policy: frame-ancestors

Content-Security-Policy (CSP) is an HTTP response header. It was designed primarily to protect against Cross-site Scripting (XSS) attacks. Currently, it also includes an anti-clickjacking frame-ancestors directive. This directive controls how the page can be embedded by different sites by specifying parent pages that may embed the page. Embedding control covers the following tags: <frame>, <iframe>, <embed>, <object>, and <applet>.

How To Use the CSP frame-ancestors Directive

Content-Security-Policy may only be used directly as a response header, it cannot be used in meta tags. The best option is to configure your web server to automatically include it with every page that it serves. The frame-ancestors directive is just one of the many directives that you may use.

This is an example of the CSP frame-ancestors directive that allows the page to be embedded only in itself and in Acunetix web pages:

Content-Security-Policy: frame-ancestors 'self' '\*.acunetix.com';

For full information on other Content-Security-Policy directives, see the Mozilla developer article about CSP.

Advantages and Disadvantages of the CSP frame-ancestors Directive

The frame-ancestors directive is very versatile. It has many options that let you whitelist hosts and schemas. You may also include several CSP headers to cover multiple use cases.

However, frame-ancestors is still quite a new concept and several older browsers do not support it. The biggest problem lies in complete lack of support in Internet Explorer (any version). This browser is still quite popular, so the frame-ancestors directive alone is not enough to protect all users. It must be used together with other defense mechanisms, for example, the X-Frame-Options header. However, older versions of Firefox and Chrome go against the official CSP definition. They ignore the frame-ancestors directive if the X-Frame-Options header is present, while it should be the other way around.

To see the full browser compatibility chart for CSP frame-ancestors, visit the Mozilla developer page for the frame-ancestors directive.

X-Frame-Options

X-Frame-Options (XFO) is an HTTP response header. It was introduced in 2008 in Microsoft Internet Explorer 8. However, it was never accepted as an official standard (despite the IETF publication RFC 7034 from 2013). This response header is a simple predecessor of the frame-ancestors directive. Formally, CSP frame-ancestors obsoletes the X-Frame-Options header.

How To Use X-Frame-Options

X-Frame-Options may only be used directly as an HTTP header, you cannot use it in meta tags. Just like in case of CSP frame-ancestors, your best option is to configure your web server to automatically include it with every page.

You may only use the X-Frame-Options header once for a page. If you specify it more than once, one header overrides the other. This is an example of an X-Frame-Options header: the web page may only be embedded by pages that begin with www.acunetix.com (but not acunetix.com):

X-Frame-Options: allow-from https://www.acunetix.com/

Advantages and Disadvantages of X-Frame-Options

The X-Frame-Options HTTP header remains the most commonly supported clickjacking protection option. It is currently supported by all major browsers but not in its entirety. Unfortunately, Chrome and Safari do not support the allow-from directive. They only support deny and sameorigin directives. Due to the popularity of Chrome, it is therefore recommended not to use the allow-from directive at all.

The X-Frame-Options header is very limited. This introduces difficulties for website designers. For example, users of the Jenkins CI solution cannot include Jenkins frames in other pages due to the X-Frame-Options policy.

To see the full browser compatibility chart for X-Frame-Options, visit the Mozilla developer page for the X-Frame-Options header.

Framebusting

Framebusting (also known as framebreaking or framekilling) is a client-side technique. It does not require any modifications to HTTP headers. All you need to do is modify your web page HTML code. It is the most generic method to protect against clickjacking and works even in legacy browsers (such as IE6). However, it is not as reliable as HTTP header options and in some cases may be circumvented (for example, in Internet Explorer 8 by loading the content into <iframe security=restricted>).

A good general framebuster script to use was published on Codemagi in 2010 and is still valid:

<style id="antiClickjack">body{display:none !important;}</style>
<script type="text/javascript">
if (self === top) {
var antiClickjack = document.getElementById("antiClickjack");
antiClickjack.parentNode.removeChild(antiClickjack);
} else {
top.location = self.location;
}
</script>

Do not use <script>if (top!=self) top.location.href=self.location.href</script> to protect your web page from clickjacking. This is a very old method that can be easily circumvented in a number of ways.

How To Check If My Site Is Vulnerable?

Manually checking your every web asset for clickjacking vulnerabilities would be a tedious process. Fortunately, the Acunetix vulnerability scanner automatically checks for the existence of the X-Frame-Options header and the CSP frame-ancestors directive on all your websites and in all your web applications. Take a demo and make sure that your web assets cannot be used as tools in a clickjacking attack.

VISIT THE SOURCE! — https://www.acunetix.com/blog/web-security-zone/defend-against-clickjacking-attacks/