AppSec Blog: Category - Clickjacking

AppSec Blog:

Clickjacking: Help, I Was Framed!

Security researchers discovered and disclosed the Clickjacking attack (also known as a "UI Redress Attack") back in 2008. All major browsers were affected. Flash even had an interesting vulnerability that allowed control of a user's microphone and webcam. Yet, here we are 7 years later still citing this issue on nearly every security assessment of web applications that we do. During our report delivery, development teams typically have one of the following responses: "What's Clickjacking?", "What can someone really do with this?", or "So what?".

I'd like to take a minute to explain a little bit about this exploit, give a quick example, and talk about a few ways to mitigate this issue.

The Exploit

Clickjacking involves hosting a form from the application in an iframe and tricking the user into activating the form. A common way to do this is to set the opacity of the iframe to 0 (rendering it invisible) and placing a link over a button on the


Adoption of X-FRAME-OPTIONS Header

Late 2008, Jeremiah Grossman and Robert Hansen publicized the clickjacking problem and got the web app security experts all trying to come up with solutions. One of the more viable solution is the X-FRAME-OPTIONS header that allow a site to control whether its content can be within a frame. There are two settings to this header, DENY blocks the content from being in a frame and SAMEORIGIN only allows the content to be framed by pages within the same origin. While it is not the end all and be all of clickjacking solution and won't work in some sites that extensively use frames across multiple sites, it is considered as a more reasonable approach for sites to protect their own content.

Johannes Ullrich and I got a little curious