Facebook Adds Code for Clickjacking Prevention

Over the last several months, many Facebook users have fallen prey to clickjacking “worms.” Lured by tempting links on a friend’s wall, victims would click through to a page that seemed to promise interesting photos or other info. But the page instead contained an invisible inline frame that loaded Facebook’s share page. When a user clicked for their prize, they instead posted the attack page to their wall as well. In at least one case, the attack page also tried to install malware.

In each case, Facebook responded fairly quickly, and one benefit to the site’s centralized nature is that administrators can purge known links to clickjacking attacks from walls across the system. Still, by the time such problems become known, myriad users may have already been compromised. Posting shared links may not cause much damage, but this blog has outlined before how much is truly possible with clickjacking. It’s long been possible for attackers to use clickjacking for installing applications, thus harvesting user data before Facebook cuts off viral channels. As with many security risks, though, there seems to be a lag time between discovery of potential and actual exploitation. Even the basic clickjacking attacks of late have been possible for quite a long time before they first surfaced.

Given the many threats posed by clickjacking, I’ve been surprised that Facebook has never seemed to show an interest in implementing code aimed at blocking an attack. After similar “worms” appeared on Twitter, the microblogging site added framebusting JavaScript to reduce the risk. Completely avoiding clickjacking is difficult (if not impossible apart from added browser protections), but such measures certainly make it much more difficult.

But quietly, Facebook has fortified their code. I’m not sure how long the new protection has been in place – I’ve not seen it reported anywhere, and only noticed it this week. The only mention I saw of it on Twitter came only a few days previous. In any event, Facebook deserves praise for the change, and I personally find their current solution rather clever.

On high-risk pages (possibly every page, but I’ve only checked high-risk ones, such as for link sharing and application authorization), a block of code checks whether the page is “top” – that is, whether or not it’s inside of a frame. If the page finds itself “framed,” an image is loaded that notifies Facebook, and a div element is loaded on top of the page. The div is set to cover every element in the page, and adds a dark filter if visible. Finally, the div has an onclick event set which loads the Facebook page outside of the frame. Thus if someone clicked a link hiding an invisible Facebook iframe, they would only click the div and see the page reloaded in the full window.

An immediate weakness is that this requires JavaScript to work, but you’ll find it’s rather hard to use Facebook without JavaScript enabled. That may be disappointing from a usability perspective, but it’s certainly a plus in this context. In particular, authorizing an application appears to require JavaScript.

I’m very glad to see Facebook add an innovative way of protecting their users from clickjacking attacks. This change adds a layer of difficulty to several Facebook attacks I’ve described in the past. Granted, there are still many ways that applications can be exploited, but this new code may remove at least one attack vector.