Start tracking your progress
Trailhead Home
Trailhead Home

Prevent Clickjacking

Learning Objectives

After completing this unit, you'll be able to:
  • Explain what a clickjacking attack is.
  • List three common real-world uses of clickjacking.
  • Change your org configuration to prevent clickjacking attacks.

What Is Clickjacking?

Clickjacking is a common web application vulnerability that hit its peak in the early 2000s. This attack is used by malicious actors to trick users into thinking that they are interacting with one object while they are actually interacting with another.

On a clickjacked page, the attacker displays some benign content to the user while it loads another page on top in a transparent layer. On the clickjacked page, the users think they are clicking buttons corresponding to the bottom layer, while they are actually performing actions on the hidden page on top.

Clickjacking in Action

Let’s check out how this would work in your Kingdom Management developer org.
  1. Log in to the Kingdom Management developer org and select the Kingdom Management app.
  2. Click the Disloyal Subjects tab.

    On this page, you’ll see a basic form that enables you to banish disloyal subjects by reassigning their work location when you click the Send to the High Tower link. Let’s see how an attacker could use clickjacking to convince an end user to banish personnel without their explicit knowledge.

  3. Navigate to the Clickjacking app.
  4. Click the Clickjacking Vulnerable Demo tab.

    At first glance, this looks like any normal Visualforce page. You see a table showing the list of current banished personnel with a large banner above it enticing you to click it.

  5. Click the Click Here button on the You Found Treasure! banner.
  6. Refresh the tab.

You’ll notice that the number of banished personnel increased by one. Wait, how did that happen? It becomes clear when you look at the Visualforce code.


.clickjackframe {
    top: -40px;
    left: 200px;
    height: 300px;              
    //Comment below 2 lines to see what is behind image

<iframe class="clickjackframe" frameBorder="0" allowTransparency="true" style="background-color:none transparent; filter:alpha(opacity=0)"  src="/apex/Vulnerable_Clickjacked_Form"/>

<img height="150px" width="400px" src="{!$Resource.Clickjacking_background}"/>

The attacker included an iFrame in this page that references the contents of the disloyal subjects form that we looked at before. However, as a user you don’t see this form because the attacker cleverly set the transparency of the iFrame to 0, rendering it invisible. Next, the attacker modified the CSS properties of the iFrame to position it directly on top of the button. When a user clicks the button, the user is actually interacting with the transparent iFrame above it. Resulting in a person being banished.

Below is a screenshot of the demo page with the iFrame opacity increased so you can visualize the attack easier:

Screenshot showing hidden iframe in demo org

Other Common Uses of Clickjacking

Our simple example showed how clickjacking can be used to modify data in your Salesforce instance. However outside of the Salesforce platform, this type of attack has been used for a number of different malicious activities including:

  • Tricking users into enabling their webcam and microphone through Flash (also known as Cursorjacking).
  • Tricking users into making their social networking profile information public.
  • Downloading and running malware, enabling a remote attacker to take control of others’ computers.
  • Making users follow someone on Twitter.
  • Sharing or liking links on Facebook (also known as Likejacking).
  • Clicking Google AdSense ads to generate pay-per-click revenue.
  • Playing YouTube videos to gain views.
  • Following someone on Facebook.

Prevent Clickjacking Attacks

So now that you understand what a clickjacking attack is, how do you prevent it? There are a few commonly employed techniques to prevent clickjacking, each with limitations.

Use Frame-Busting Scripts

The most commonly used approach is to use a “frame-busting“ script to prevent an attacker from loading your website in an iFrame. The script attempts to detect if the page is loaded in a frame. If detected, it will prevent the page from loading. For this technique to work, a site owner has to include the script on every site page.

Here are some examples of frame-busting scripts:

if (top != self) top.location = self.location;
if (top.location != location) top.location = self.location;
if (top.location != location) top.location.href = document.location.href;

While this is the most popular solution to clickjacking, a lot of frame-busting scripts have known bypasses that an attacker can use to get around this protection.

Use X-Frame Options

Another clickjacking protection is to use an HTTP header introduced in Internet Explorer® 8 called X-FRAME-OPTIONS. This header works like frame-busting scripts in that it enables the site owner to set restrictions on where pages can be loaded.

This header can be set to one of three values:

  • DENY — Prevents the page from loading in a frame completely.
  • SAMEORIGIN — Allows framing only if the origin is the same as the content (for example, versus
  • ALLOW-FROM — Enables framing only from a specific URL.

Depending on your user base, enabling this header might not be a full solution since a lot of legacy browsers don’t support X-FRAME-OPTIONS.

Use Salesforce Clickjacking Protection

Salesforce leverages both of these methods (frame-busting scripts and the X-Frame Options header) as standard clickjacking protection. You can view your protection settings in Setup. Enter Session Settings in the Quick Find box, then select Session Settings.

Clickjacking Salesforce Setting

By default all standard Salesforce pages are protected against clickjacking; however, as a developer you can extend this protection to your custom Visualforce pages. Before you enable this functionality, check with your Salesforce admin. If your applications make extensive use of iFrames, clickjack protection may break intended functionality.

One last note. If you enable this setting in your Kingdom Management developer org and retry our attack page, you’ll notice that the attack is still successful. Why?

For demo purposes, both the vulnerable form and the attack page were hosted in the same domain (your Salesforce instance) so the X-Frame-Options: SAMEORIGIN header set by platform will continue to allow the framing. If you were to try to perform this same attack on an external server, it would be blocked.