Every time we add a new web page to our site we take for granted the possibility of this page being framed. Among the many advantages of this default web page property lays a major disadvantage.
Enter clickjacking. Using some clever CSS an attacker can frame a web page in a transparent iframe and put it on top of what appears to be a normal web page. The users, unaware of what’s actually happening, are happily interacting with the web page in front of them while in the background (or in this case the transparent foreground) the real action is taking place. Something the users wouldn’t normally do. Adding a dodgy Facebook app or Liking a random Facebook page, following random Twitter users or deleting their entire Twitter account, making a single-click purchase they don’t want or allowing access to their web cam and microphone. The list goes on.
The Facebook "Like" worm is a good example of a recent targeted clickjacking attack. Luckily the end result was lots of users Liking a random Facebook page set up by the attacker. The severity of these attacks can be much greater.
A recent Stanford University case study shows that out of the Alexa Top 500 sites only 14% use some form of clickjacking prevention mechanism. The clickjacking concept was introduced to the public a couple of years ago, yet these figures suggests that possibly not many site owners are aware of the vulnerability or they are aware of it but don’t consider it to be a critical risk, which it is. Maybe it’s the fact that currently there’s no definitive solution that can completely eliminate clickjacking.
Even though there’s no silver bullet against a targeted clickjacking attack there are two things you can easily do today to limit the possibility of this happening – Frame busting and X-FRAME-OPTIONS.
Frame busting is a simple JavaScript patch you can apply to all the pages you want to protect. It can be accompanied by some basic CSS for better user experience. Implementations vary from a couple of lines to a couple of dozen lines. This is the implementation proposed by the above mentioned case study:
The script checks to see if the page is running inside an iframe. If so then it breaks from it, otherwise it reveals the page content which is initially hidden using CSS. This requires the user to have JavaScript enabled in their browser, otherwise they’ll see a blank page. Considering JavaScript is required for this implementation accessibility becomes a bit of an issue. For user accessibility you can modify the script and CSS to display a user friendly message advising them to enable JavaScript if they want to use the page. At the same time you can offer an alternative option to achieving the same result that doesn’t require JavaScript to be enabled. This is not something you would apply across your whole site, although forms exchanging sensitive user information do deserve your attention.
X-FRAME-OPTIONS is a response header supported by the latest versions of all major browsers except Firefox (without the NoScript plug-in, which is worth installing if you’re a Firefox user). Similar to the frame busting code, you send this response header down with all the pages you want to protect. Depending on the technology you use it should really be one-liner specifying the header value DENY or SAMEORIGIN. The following works for a .NET site running in Classic mode:
DENY will prevent the selected page from being framed by any internal or external pages. SAMEORIGIN will prevent the selected page from being framed by external pages only.
Depending on the users’ browser they’ll either see a blank frame (Safari and Chrome) or a message advising them the page content can’t be displayed inside a frame and suggesting they open the page in a new window (Internet Explorer and Opera).
Hopefully browser vendors are already working on a permanent solution and clickjacking will be a thing of the past when they release their new upgrades. Until then applying these two patches will keep your sites as safe as possible.