Cyber attackers are continuously cultivating their methods to evade detection. Now, they can cloak a seemingly innocuous webpage with an invisible layer containing malicious links. This method of attack, known as clickjacking, could cause you to activate your webcam or transfer money from your bank account.
In this post, we outline the different types of clickjacking attacks and teach you how to best defend yourself against this application security threat.
What is Clickjacking?
Clickjacking (or click hijacking) is a type of cyber attack where an unseen malicious link is placed over a website's user interface. Because clickjacking occurs on an invisible iframe layer loaded on top of a legitimate page, visitors usually cannot identify when a clickjacking attack is taking place.
There are two victims in a clickjacking attack - the host website and the visitor. The host website is used as a platform to facilitate the clickjacking attack, and the visitor becomes a victim to the specific intention of the attack.
Some common types of clickjacking attacks include:
- Login credential theft
- Webcam or microphone activation
- Invitation of malware downloads
- Authorization of money transfers
- Unsolicited product purchases
- Identifying your location
Clickjacking intentions are not limited to this list. Because user interfaces can be cloaked with any type of link (UI redressing), the destructive options are limitless.
Clickjacking Examples
Here are some examples of the most notorious types of clickjacking attacks.
Money transfer scams
In this UI redress attack, an attacker tricks you into clicking a link on a malicious page that authorizes the transfer of money from your bank account.
Here's an overview of the process:
First, the victim is presented with a seemingly innocuous website that could be loaded from a link in an email. Such websites usually promote an irresistible offer, like a free gift or a holiday deal.
When the website loads and the victim clicks the button to claim their 'free gift', they're actually clicking on a funds transfer confirmation link on an invisible web application layer. If the victim is logged into their bank at the time, their money will instantly be transferred to the attacker's account.
While the unsolicited transfer is taking place in the background, the victim is redirected to a page with more information about their 'free gift.'
Webcam and microphone activation
In this clickjacking attack, a user's adobe flash settings are invisibly loaded over another link. When the infected link is clicked, users modify their adobe flash plug-in settings to give attackers access to their webcam and microphone.
Likejacking
In a likejacking attack, users are tricked into clicking a Facebook page "like" button when they click on a presented link. A user needs to be logged into Facebook when the link is clicked for the attack to be successful.
Social media accounts are also vulnerable to clickjacking. Twitter fell victim to a successful attack in 2009 known as a tweet bomb.
The tweet bomb was a continuous cycle of users clicking on a tweeted link, then clicking a clickjacked link in the opened web page, which then tweeted that original link on their account, promoting their followers to click the link, etc.
Cursorjacking
cursorjacking is a form of clickjacking where a duplicate cursor is created and attached to the real cursor at a specified offset. Only the duplicate cursor is visible. If there's a specific area of the screen the attacker knows the user will click on, they can strategically offset the real hidden cursor so that when the fake cursor is maneuvered to this area, a malicious link is clicked.
Cursorjacking was possible due to vulnerabilities in Firefox. These security flaws have been amended in Firefox 30.
Malware downloads
An attacker could initiate the download of malware when a user clicks on a hijacked link. Malware can corrupt the software of a system or establish a gateway for advanced persistent threats.
Preventing Clickjacking attacks
If you wanted to measure the vulnerability of your website before implementing clickjacking defenses. refer to this OWASP clickjacking cheat sheet.
Clickjacking mitigation can be achieved on both the client-side and the server-side. Let's discuss the options for both scenarios.
Server-side clickjacking prevention
Many clickjacking attacks occur on duplicates of legitimate websites. An attacker could clone your website and weaponize it with hijacked links hidden on top of it. Besides the devastating consequences for users, your business could suffer irremediable reputation damage.
You need to, therefore, ensure that none of your web pages can be wrapped in a <FRAME> or <IFRAME> tag.
There are two ways you can do this:
1. Specify the correct Content-Security-Policy frame-ancestors directive.
The Content Security Policy (CSP) with its frame-ancestors directive, is a highly effective cybersecurity tactic against webpage embedding.
Besides protecting your website from iframe embedding, the Content-Security-Policy also protects your website from cross-site scripting (XSS), one of the most common types of cyber attacks.
To implement this defense you need to first ensure your web server is set to return the Content-Security-Policy. Once CSP has been added to your website, the appropriate CSP frame-ancestors directive response headers can be set to disallow embedding.
The frame-ancestors 'none' directive will prevent all domains from embedding your website in a frame.
For example:
Header set Content-Security-Policy "frame-ancestors none;"
If you wanted to enable embedding by your domain only, you would enable the frame-ancestors 'self' directive as follows:
Header set Content-Security-Policy "frame-ancestors 'self';"
To permit a domain outside of your own to embed your web pages, you need to use the 'data:' scheme and specify the whitelisted URI. This, however, is not a secure method and can be bypassed by injecting multiple arbitrary data: URIs.
2. Specify the x-frame-options deny directive
The x-frame-options response header specifies whether a browser is permitted to embed your web pages in a frame.
The x-frame-options response header will eventually become obsolete and replaced by the frame-ancestor directive so it should not be your primary method of defense.
To send the correct x-frame-options HTTP headers from your website resources, you need to set the directive to 'deny.'
For example:
X-Frame-Options: DENY
Once your x-frame-options is set to the deny directive on the server-side, all attempts to load your website in a frame will be blocked. This is equivalent to the frame-ancestors none defective of the Content Security Policy.
If you wanted to permit framing by your own domain only, you would set the same origin directive as follows:
X-Frame-Options: SAMEORIGIN
This is equivalent to the frame-ancestors self-directive of the Content Security Policy. it will only permit framing of your web content if the parent shares the same origin.
Client-side clickjacking prevention
Client-side clickjacking prevention isn't as effective as server-side prevention tactics. These methods should be implemented as a secondary option.
1. Frame busting scripts
Frame busting scripts prevent your website from functioning inside a frame. Via Javascript add-ons, you can specify how a browser should react when your page is loaded in a frame.
A common frame buster technique is to force the browser to reload the offset decoy web page at the top window. By doing so, the decoy website is loaded on top of the malicious iframe layer.
This action can be prompted with the following lines of Javascript:
<script>
if (top != window) {
top.location = window.location;
}
</script>
This defence can, however, be easily circumvented. The attacker could block the forced reload attempt with the following lines of Javascript:
<script>
window.onbeforeunload = function() {
return false;
};
</script>
Another way frame busting scripts can be circumvented is by using the HTML 5 iframe sandbox attribute.
Here's an example of the Javascript code:
<iframe id="decoy_webpage"
src="https://decoy-website.com"
sandbox="allow-scripts allow-forms allow-same-origin">
</iframe>
By omitting the allow-top-navigation attribute, the iframe containing the decoy web page cannot be loaded on top of the invisible page. With this defense in place, the attacker is able to permit the browser to run scripts and submit forms.
Frame busting scripts are not a recommended defense against clickjacking attacks. Many web browsers block frame busting Javascript code and the browsers that don't can be easily tricked to permit the malicious overlay.
A study by the Standford Web Security Group outlines the clickjacking vulnerabilities of frame busting methods.
2. Install browser extensions
Anti-clickjacking browser extensions don't provide the best user experience because they disable all the javascript on loaded websites. Many popular websites like Facebook, Twitter and Youtube run on Javascript and these extensions will impede their functionality.
To maintain the Javascript experience on trusted sites, you would need to manually specify a whitelist
Here's a list of Javascript blocking add-ons for different browsers
Chrome
Scriptsafe is an extension for Chrome.
Mozilla Firefox
NoScript is a Mozilla Firefox browser add-on.
Safari
JS Blocker is a Safari browser extension.
Microsoft Edge
Javascript Toggle ON and Off is an add-on you can install on Microsoft Edge.
DuckDuckGo
Duckduckgo doesn't have a Javascript blocking add-on you can install, but they do offer an alternative browser specifically developed to block Javascript websites. You can access this browser here.
Internet explorer
To disable Javascript on internet explorer, follow this process:
- Select the gear icon in the top right corner or press ALT+X
- From the drop-down menu select 'Internet options'
- Click the 'Security' tab
- Click 'custom level'
- Under 'Active Scripting' select 'Disable-ON'
- Select 'Yes' to confirm
