Clickjacking in Plain English

In another blog post, I discussed a vulnerability called Cross-Site Request Forgery (CSRF) that allows an attacker to force a victim to perform actions on their logged-in sites inadvertently. The defense I recommended was called the Synchronizer Token Pattern, as the defense relies on using randomly-generated tokens to which attackers would not have access. Hackers are both clever and resourceful, however, and if your website is vulnerable to a technique called clickjacking, attackers can force victims of your site to perform unwanted actions even if proper CSRF protections are in place.

Clickjacking is a sneaky trick that relies on the ability to place a victim website in an iframe on another website. Through the clever use of an invisible iframe and precise overlaying, an attacker may be able to convince a user to click on a what looks like an innocent button on their site, but is actually a button or link on the invisible iframe. The invisible button in the iframe is typically positioned so it is exactly in the location where the user is likely to click, but some attackers take this further and use Javascript to have the invisible iframe follow the mouse pointer around the page, making the attack possible no matter where the user decides to click.

This attack is best understood visually. Let’s suppose, only for illustration, that eBay is vulnerable to clickjacking—meaning that an attacker could embed an eBay page in an iframe on their own site. A product listing page looks like the following.

An attacker can construct a website that contains a really enticing button, just begging to be clicked.

Then, they can precisely overlay the eBay iframe so that the “Buy It Now” button sits perfectly on top of the “FREE” button. The following uses a semi-transparent iframe for illustration purposes.

Lastly, they can make the iframe invisible, yet still technically “on top of” the site’s content, so when the user thinks they’ve just clicked on a link, they actually became proud owners of a new car.

The Danger

In the above example, an attacker can trick an unsuspecting user into buying a Ford. Even if the “Buy It Now” button is inside of a CSRF-protected form, the request goes through, the website has no way to distinguish an intentional click from one contrived by an attacker. This same attack can be used to cause the user harm, such as tricking them into deleting all of their emails by lining up the “Delete All” button under the “FREE” button. An attacker could also trick the user into opening themselves up to further attack by disabling defenses and enabling your webcam. If that’s not scary enough, or you already cover your webcam with black tape, an attacker can construct a precise combination of malicious text fields and buttons and trick a victim into resetting their password for another service.

The Answer

To prevent this attack, you need to prevent the ability for your site to be embedded as a frame in another site. There are two ways to solve this. In short, there is the established way and the new way. Since we’re in the middle of a transition phase—the new way is still very new and not widely supported—I recommend doing both, to prepare yourself for the inevitable day when the old way is deprecated.

The Established Way

The common way this is done is by adding an HTTP header that serves just this purpose: X-Frame-Options. As you may know, the X- prefix indicates that this is a non-standard header; however, this header is understood by all major browsers, including Chrome, Safari, Opera, Firefox, and Internet Explorer 8 and newer. Browsers refuse to load content in an iframe if that content includes this header and the header disallows it. The header has two possible values: DENY, and SAMEORIGIN. DENY is self-explanatory, and SAMEORIGIN allows the page to be embedded only within the same domain as the embedding site. There does exist a third option called ALLOW-FROM uri, but neither Chrome nor Safari plan to support it. Therefore, I do not recommend using ALLOW-FROM at all.

The New Way

There’s a new all-encompassing HTTP header that’s on its way to becoming a standard. It’s called Content-Security-Policy (CSP). The Content-Security-Policy header enforces whitelists for trusted content that is allowed to be loaded along with your webpage. You can use it to mitigate XSS by whitelisting JavaScript sources and disabling inline JS entirely, you can use it to mitigate unvalidated redirects with a whitelist of trusted redirect sources, and you can even have the browser report security violations back to your web application so you can fix your potential security holes. Even though it’s still in draft form, there is already a second version of CSP that includes a directive called frame-ancestors, a whitelist of trusted sources that are allowed to include your page in a frame.

If you want to prevent framing of your page entirely, use the CSP header like this:

Content-Security-Policy: frame-ancestors 'none'

To allow framing only within your own site, you can replace 'none' with 'self'. Alternatively, you can supply a list of allowed, trusted domains. Like all aspects of CSP, it’s very flexible.

Content-Security-Policy: frame-ancestors

You can use an automated web security scanner like Tinfoil to crawl your site and ensure that no page is vulnerable to clickjacking. Tinfoil provides the best web application security solution on the market, and it detects clickjacking vulnerabilities on your website along with many other types of web vulnerabilities.

Angel Irizarry

Angel Irizarry is the Software Samurai of Tinfoil Security, and a self-proclaimed software purist. All he needs to do his best work is a plain Linux machine with Git and Emacs installed. He loves everything about front-end development, like making pages interactive and super fast, even if that means digging in and optimizing some SQL. When he's not writing code, which isn't very often, you'll find him on his iPad scouring his RSS feeds for news and rumors of cool new gadgets.

Tags: plain english clickjacking

Tinfoil Security Blog

Tinfoil Security provides the simplest security solution. With Tinfoil Security, your site is routinely monitored and checked for vulnerabilities using a scanner that's constantly updated. Using the same techniques as malicious hackers, we systematically test all the access points, instantly notifying you when there's a threat and giving you step-by-step instructions, tailored to your software stack, to eliminate it. You have a lot to manage; let us manage your website's security.