August 20, 2015

Last Updated on January 17, 2024

Clickjacking, also sometimes called a UI redress attack, deceives website visitors and directs their clicks to the attacker’s choice of elements on another website. I find this longstanding vulnerability in almost every web application I test. (I even found it recently on Amazon.com.) Yet few developers I talk to seem to be aware of how prevalent these vulnerabilities are—or how easy they are to mitigate.
Clickjacking is frequently used to hijack accounts for spamming purposes or propagate links to malicious websites on Facebook. But it can also be used to trick website visitors into granting attackers access to confidential data or taking control of their computers. For example, a clickjacking vulnerability could be a “back door” for a more deadly exploit like a cross-site request forgery (CSRF) attack.
Since it was originally described in 2008, several popular clickjacking exploits have emerged. The most sensational was undoubtedly the hijacking of users’ webcams and microphones using Adobe Flash, effectively turning their computers into remote surveillance devices. The infamous “Twitter worm” of 2009 also made big headlines.
Clickjacking can be highly effective and is undoubtedly on the rise, especially on social media sites. Admittedly it is challenging to manipulate, but hackers are becoming more adept. Yet according to research conducted in 2010, only a handful of “top 500” websites are defended against clickjacking.
How does clickjacking work? The attacker overlays a web page with an “invisible” iframe, tricking a user into clicking a button, link or image other than the one they think they’re clicking. Keystrokes can also be hijacked using a similar technique.
In this example, a user is asked to click a “free trip” link.
clickjacking-example-01
But as this second image shows, an attacker has overlaid a bogus frame with opacity set to zero. The user won’t see that he or she is actually about to charge purchases to their credit card.
clickjacking-example-02
Fortunately, clickjacking is straightforward to defend against. The most effective methods involve including “frame-breaking” code in your applications to prevent other web pages from framing your site. Either of two approaches are commonly used for this: changes to the X-Frame-Options header, or JavaScript code.
The former technique simply involves setting X-FRAME-OPTIONS in the website’s response header to DENY, so that the website won’t accept an iframe from any other website:

HTTP/1.1 200 OK
Server: Apache
X-FRAME-OPTIONS: DENY
Date: Tue, 21 Jul 2015 20:54:56 GMT
Content-Length: 34567

You could also set X-FRAME-OPTIONS to SAMEORIGIN, which allows the current site to frame the content.
The above fix works only for newer browsers. If your application needs to support legacy browsers (e.g., Chrome 4 or Internet Explorer 34-bit) that don’t support the X-Frame-Options-Header, you can put this JavaScript from OWASP in a document HEAD element:

This script first applies an ID to the style element itself, then deletes the style by its ID immediately afterwards. This allows all the code to reside in the document HEAD so you only need one method/taglib in your API.
As you can see, these forms of mitigation are easy to implement even for a production application, and won’t impact a development lifecycle.
It’s time to start taking clickjacking seriously. The potential damage this attack could inflict is badly underestimated. To discuss how to test for clickjacking and other vulnerabilities in web applications, contact Pivot Point Security.
For more information on clickjacking: