Facebook Platform Vulnerability Enabled Silent Data Harvesting

A few weeks ago, I sent Facebook a demonstration of what appeared to be a previously unknown attack combining two behaviors of the Facebook Platform. The technique allowed one to create a seemingly innocent web page that would invisibly and silently steal a visitor’s private Facebook content. Facebook has now disabled the attack by modifying one of the exploited behaviors.

It’s unlikely that any real-world attacks used this particular vulnerability, and I certainly have no record of such a case. But it’s also unclear how long the problem has existed. I discovered one part of the technique, a “return_session” parameter for application authorization, while examining the behavior of the Yahoo! contact importer, which only launched a month ago. However, discussions on Facebook’s developer forum mention the parameter in the context of Facebook Connect implementations as far back as February 2009. The other main component, now modified by Facebook, may have existed since the beginning of the Platform in 2007.

In my proof-of-concept demonstration, I loaded a harmless-looking web page on a server external to Facebook. The page included code for an inline frame sized to be invisible to the user. This frame then loaded the login page for a Facebook application. If the user has already authorized an application, its login page will automatically forward to the application, and that’s exactly what I wanted to happen. I chose FarmVille for my demo, since it has a wide install base. Keep in mind that while FarmVille currently lists about 83 million monthly active users, the attack would have worked for anyone who has authorized the application, regardless of how long ago. The attack could also target multiple applications at once using multiple iframes, meaning nearly any of Facebook’s 400 million active users could have fallen prey.

But the first main component of the attack involved a slight modification to the login page URI. By adding a “next” parameter, one can specify an alternate landing page for authorized users. Not all applications take advantage of this parameter, but many do. The parameter would not work for an arbitrary site, but Facebook previously did allow any URI that began with apps.facebook.com. Thus one could craft a login page URI that checked whether the user had authorized one application and then forward the user to a second application.

The next part of the attack came from adding “return_session=1″ to the login page URI. This parameter causes Facebook to append particular session variables for the authorized application onto the URI of the landing page – in our case, the second application given by the “next” parameter. That application merely has to check its address for the session data, which provides enough information to execute API requests using the credentials of the already authorized application. Since an authorized application essentially operates on behalf of a user, it has access to nearly all private profile information (essentially, everything but your e-mail address and phone number) and content (photos, links, notes, etc.) that can be loaded via the API, and hence the second application had such access as well. This entire process could be fully automated without any user interaction and did not require any authorization for the second application. Also, the attack could generally be executed quick enough to avoid Facebook’s measures for detecting when their pages are loaded in frames.

To patch the attack, Facebook has restricted the “next” parameter; it now only forwards to addresses for the application specified on the login page, preventing any appended session data from reaching the wrong destination. Since an authorized application already has API access, using return_session with that application will not add any new privileges.

I commend Facebook for responding quickly to this issue and for being open to white-hat security reports. But in my opinion, this vulnerability is simply the latest reminder that the Facebook Platform can open users to many problems quite separate from the security of Facebook itself. I personally think that aspects of the Platform’s implementation fail to match user expectations of privacy, as I’ve discussed previously. And while this particular problem may be solved, vulnerabilities in specific applications and the nature of application access continue to put private data at risk of unwanted disclosure.