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.
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.
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
Date: Tue, 21 Jul 2015 20:54:56 GMT
You could also set X-FRAME-OPTIONS to SAMEORIGIN, which allows the current site to frame the content.
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 nead 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:
- An excellent discussion of how clickjacking attacks work
- The OWASP clickjacking defense cheat sheet
- Specific information about clickjacking on Facebook
- Discussion of clickjacking threats on the W3C web security wiki
- A discussion of “frame buster busters” with lots of detail
- OWASP guidance on how to test for clickjacking vulnerability in a web application