What is clickjacking?

Clickjacking is just one of the many strategies hackers use to steal data or get victims to do something they didn't mean to do. Through some clever design strategies, it makes the user think they're clicking a different button than they really are. It can be used in everything from stealing bank credentials and authorizing payments to downloading malware and liking social media pages. 

It's a sly little trick that requires both server-side and client-side defense mechanisms. Fortunately, best practices have been developed to prevent clickjacking and help users avoid falling into its traps. With the Box Content Cloud, we follow those practices for our own programs and encourage them for our partners.

Let's take a closer look at clickjacking, how it works and what you can do to prevent it.

What is clickjacking?

Clickjacking is something called a user interface (UI) redress attack. Essentially, the hacker creates a transparent layer, or frame, on top of a webpage. Then, when the user tries to click on a button on the webpage they see, they actually click on an invisible unexpected webpage element just above it in the transparent layer. That layer is an HTML element known as an iframe.

One example of a clickjacking attack is a "Claim Your Prize" page that boasts a monetary award. When the person visits the page, it checks in the background to see if the user is logged into their banking account. It then generates the banking site's webpage in a transparent frame above the "Claim Your Prize" button. When the user attempts to click the button, they're actually initiating a bank transfer to the attacker. 

This method could apply to any number of other malicious webpage attacks, too, like downloading a virus, creating new social media posts, or sending over private information.

The term was developed because this process essentially hijacks your click. You click the link meant for one page and are routed to another one. Clickjacking can also refer to using the invisible frame to hold text input fields. Someone could see the legitimate website of their bank, so they enter in their password. But there's actually an invisible field above the site, so they send their password right over to the hackers. 

Those fields can be a little harder to pull off than the button-based attacks because users will typically stop typing when they see that their keystrokes aren't showing up.

Clickjacking attacks can be especially dangerous since they often work from a logged-in account. The invisible button might be a button to initiate an action such as a bank transfer or liking a page on social media. It uses the victim's credentials to authorize the action. 

Because the action was technically performed by the user, these attacks are often not traced back to the attacker. This type of authorization leads to the Infosec Institute calling it a "confused deputy problem," in which the computer is fooled into misusing its authority.

Building a clickjacking attack is usually done via cascading style sheets (CSS). The attack usually focuses on creating and manipulating page layers, overlaying the target website as an iframe on the decoy site. Overlapping the pages requires precise positioning of both absolute and relative values to appear legitimate. A z-index determines the layers' stacking order, while the opacity value ensures a see-through window that the user doesn't see. Some browsers can detect this, though, so hackers will sometimes use very light opacity values to bypass that detection.

When we aim to prevent clickjacking, we usually focus on restrictions to the webpage's ability to create frames.

Clickjacking variations

Clickjacking can come in many different forms with a variety of methods. They can be as simple as one button press or as complex as requesting the user copy and paste information or place items into a cart. Multistep clickjacking will require multiple divisions or iframes and can be particularly complex.

Below are some examples of the different types of clickjacking you may encounter.

Likejacking

Likejacking is specific to social media, particularly Facebook. An invisible button above the "like" icon redirects the user to another page. This page could have malware, further scam content, or something else designed to trick the user.

Previous likejacking scams, for instance, have asked users to click a link, like the page that appeared, and enter in some personal information to receive a gift card.

Cursorjacking

Cursorjacking attacks adjust where the user perceives the cursor to be. So, a custom cursor image might be displayed but offset from where the user's actual pointer is. The user's real cursor is hidden. With this attack, the user intends to click on one thing but ends up clicking another.

Cookiejacking

Cookiejacking targets the user's cookies that are collected as they browse various websites. The user is tricked into selecting the cookie from a website and sending all of the information the cookie contains over to the attacker. Cookies can contain a range of credentials, such as login information that you save when you check the box that says, "Keep me logged in."

Filejacking

A filejacking attack takes advantage of a web browser's ability to access computer files. The user unknowingly establishes an active file server that allows the attacker access to the victim's files.

Common examples of clickjacking

A classic iteration of clickjacking involves a link that takes the user to a page claiming they've won a prize. When they click on the button to claim their prize, they instead initiate a bank transfer to the scammer. This relies on the fact that the user is logged into their bank account. The same principle applies to other hacking attempts that might use social media accounts or adjustments to computer settings.

Clickjacking has been around for a while, so there are plenty of examples of it out in the wild from before we knew to prevent them.

Below are some examples of successful clickjacking campaigns.

Adobe Flash plugin

In 2008, clickjacking attacks targeted vulnerabilities in Adobe Flash Player. The page the user opened looked like it would adjust the plugin's settings. The attacker would load an invisible frame to trick the user into modifying Flash security settings and giving permission for it to use the computer's camera and microphone. Hackers could exploit these devices for eavesdropping. 

Another clickjacking attack could use Adobe Flash as part of a classic clickjacking attack in which the user is tricked into clicking disguised site elements. Since Adobe Flash Player was widely used at the time, these hacks were concerning.

Twitter worms

Around the same time, Twitter worms were gaining traction on the social media site. Hackers could create a tweet that caused any user who clicked a link, interacted with it, or even hovered over it to retweet the content and further propagate the message. Some were harmless, like the one that just said "Don't Click," followed by a link that retweeted the message. That worm was quickly patched.

Others, however, were riskier, such as the one that opened pornographic sites in the user's browser. There were many others with effects ranging in malicious intent from adding rainbow text to creating pop-up boxes trying to scare the reader into divulging credentials. Twitter also quickly patched these worms, but not before many of its users were affected. The Guardian tells us the worm involving pornographic content was estimated to reach more than 100,000 Twitter users.

Facebook likejacking

A few years later, clickjacking tore through Facebook, bringing users to a site that instructed them to copy and paste JavaScript code into the URL. Unbeknownst to the user, they would then share the link to their friends and propagate it to more users. The images spread in these posts could be pretty disturbing, depicting sexual situations and animal abuse. Rumors said that hacker group Anonymous was behind it, but no one stepped forward.

Fortunately, we've learned a lot about clickjacking from these events, and most major websites have protections in place to keep these attacks from happening.

How to prevent clickjacking attacks

With so many disastrous possibilities, it's important to take the appropriate steps to prevent clickjacking. Just one method isn't suitable, as best practices entail supports from both the client and server sides.

Client-side methods

Client-side strategies refer to all of the activities that take place on the user's device, so what they see and what the browser displays. This is where markup languages like HTML and CSS get interpreted by the browser. Though necessary, these methods can be easy to get around. That's why they must be paired with server-side methods, too.

The most popular client-side approach is to use frame busting. This technique is based on scripts inserted in the webpage that prevent others from using it in a frame. Frame-busting scripts could ensure that the current application window is the window on top, preventing additional, transparent windows from covering it up. Scripts can also make all frames visible, restrict clicking on invisible frames, and flag suspected clickjacking attempts.

A limiting factor of client-side methods is that they are platform- and browser-specific. Some browsers have security settings that bypass or don't support JavaScript. Hackers can implement an HTML5 attribute that essentially neutralizes the frame buster. Still, it's a good first step for client-side protection that adds basic preventative measures and complicates the process for potential hackers.

Server-side methods

Server-side methods, as the name implies, occur at the server level. Too many of these can introduce excessive latency, but some server-side protections are necessary.

From the server side, you can provide better constraints for components like frames. Server-side methods are not as restricted by a browser's functionality. These methods include X-Frame-Options and content security policies (CSPs). These two approaches are generally more effective than frame-busting techniques, but both client-side and server-side methods come in handy to provide a multifaceted strategy.

Clickjacking mitigation techniques

X-Frame-Options and CSPs are some of the more effective mitigation techniques against clickjacking.

X-Frame-Options

An X-Frame-Options response header is part of the HTTP response of a page and indicates whether the browser has permission to render a page within iframe, frame, or object tags. It's been around for a while but is not an internet standard. It was primarily created specifically to defend against clickjacking. 

There are generally three options:

• DENY: No domain can display a page in an iframe
• SAMEORIGIN: The specified page can be displayed in a frame on another webpage only if the other page is in the same domain
• ALLOW-FROM URI: The specified page can be displayed in a frame only on a specific uniform resource identifier (URI)

DENY is the most secure option, but it is also the most restrictive and could affect site functionality. Most sites that use the X-Frame-Options header opt for SAMEORIGIN or ALLOW-FROM URI. Most modern browsers support the DENY and SAMEORIGIN directives, but only some support ALLOW-FROM.

There are a few drawbacks from the X-Frame-Options approach:

• X-Frame-Options does not allow for whitelisted domains, so it won't work on sites that use multiple domains
• If using the SAMEORIGIN option, the X-Frame-Options header must be returned in the HTTP response for every page and cannot be used cross-site
• Not all options are supported by all browsers, like ALLOW-FROM, so if implemented on a browser that doesn't support it, your site wouldn't have any clickjacking defense in place
• Web proxies can also remove headers and strip them from the page
• You can only use one option per page — you can't display the same page as a frame on an external site and the current website

X-Frame-Options headers can be applied in the HTTP response header on every webpage, but they can also be added in the web application firewall at the server level. In many cases, X-Frame-Options headers have been deprecated by major browsers that instead support frame-ancestors directives from CSP Level 2 specifications. Still, X-Frame-Options provide an extra layer of defense when used alongside CSP protections. It's important to consider X-Frame-Options headers in the context of your overall security strategy.

Content security policy

Modern browsers support CSPs, which allow site owners to determine the content that's allowed to load on a page. CSPs can control a wide range of values, with fetch, document, navigation, and reporting directives, among others. It can block clickjacking attacks and cross-site scripting, often through specifying server origins and script endpoints. You can even add multiple CSPs. They are usually implemented in the web server in the return header of a form.

A CSP has a valuable feature of whitelisting certain URLs, making it more appropriate for multi-domain websites. It's also more widely accepted by modern browsers — to see the details of how each one accommodates CSPs, take a look at this chart from Mozilla.

The recommended approach to clickjacking protection is usually to use the frame-ancestors directive, which defines the sources that are allowed to embed the page. It uses frame, iframe, object, embed, or applet tags. Source options include:

• <host-source>: Specifies internet hosts by name or IP address, along with optional URL schemes or port number
• <scheme-source>: Specifies schemes such as HTTP:, HTTPS:, data:, mediastream:, blob:, and filesystem:
• 'self': Refers to the page's origin, with the same URL scheme and port number
• 'none': No URLs match and can be used in the frame

Setting the frame-ancestors directive to 'none' is similar to using the DENY function for X-Frame-Options.

How Box can protect your data

Your organization's content — from contracts to presentations — is of utmost importance. Leaving it vulnerable to clickjacking is simply not an option. Say you try to drag and drop a local file into your cloud storage solution. If clickjacking protections are not in place, you could be dragging and dropping your file right over to the hackers. Here at Box, we know the importance of proper security and built it in with every service we offer.

Box employs several methods of clickjacking prevention that align with best practices. No matter how you access the Content Cloud, online or embedded, we have appropriate security measures in place. Clickjacking is just one of the many threats that we aim to protect your data from.

Our primary strategies to defend against clickjacking include an interactive widget "game" and X-Frame-Options headers.

Interactive Embed Widget

In our Embed Widget, you'll find an interactive "Drag the Cloud" game. A white cloud puzzle piece is randomly placed on the page, and the user must "plug" the cloud into a "hole" in the page. Both are randomly placed, making them hard for hackers to predict and almost impossible to clickjack. It's one of the most effective methods available for preventing clickjacking with embedded content. Hackers find it much more difficult and less worthwhile to target.

Other options

While the Box Embed Widget offers excellent protection from clickjacking, we know that not everyone wants to use that approach. We offer alternatives for those not using the widget or the cloud-game interaction. If you'd like to remove the game, you'll need to have a clickjacking defense in place that's approved by the Box security team. Your support representative can help you get started with the process, but our approved defenses include:

• Using an X-Frame-Options header
• Placing framed content in a new window
• Implementing a randomized user interaction, similar to the cloud game, before granting access to the application

These options provide appropriate clickjacking defenses for most users. Following industry best practices such as these allows us to offer the exceptional data security you can expect from Box with assurance against the threat of clickjacking. You still get to access data in the way that's easiest for you without sacrificing security.

Learn more about what Box has to offer

In the Content Cloud, Box keeps your data safe, neatly organized, and accessible from anywhere on any device. Our enterprise-level solutions are tailored to your organization's needs, with an intuitive interface, secure embedded solutions, and the features you need. We don't skimp on security either, with strategies in place for everything from clickjacking to access controls. So whether you have terabytes of data to protect or just a few files, we can keep them protected with strong information security management.

Box is more than a file storage solution — it can revolutionize your content management approach.

From marketing tools and signed contracts to collaborative documents and confidential specs, Box can house your content and add a range of capabilities like collaboration, workflow automation tools, built-in e-signatures, and the benefits of over 1,500 pre-built integrations. Link up your data with your business apps like Salesforce or Oracle NetSuite, integrate Box with Microsoft to edit files without leaving Box, and share and collaborate on files from within Zoom. With Box, you can speed up your workflow in any number of ways.

To learn more about the efficient, secure offerings of Box, please reach out to a representative today. We'll be happy to walk you through the Content Cloud and how it protects your data.

**While we maintain our steadfast commitment to offering products and services with best-in-class privacy, security, and compliance, the information provided in this blogpost is not intended to constitute legal advice. We strongly encourage prospective and current customers to perform their own due diligence when assessing compliance with applicable laws.