How Facebook’s New APIs Affect Old Security Issues

Geek level: Fairly technical at times, but makes some general points.

Based on my experience in researching Facebook security, I was quite interested in the security ramifications of Facebook’s recent developer announcements. Some of the analysis I’ve seen thus far from others actually involve rediscovering previously reported concerns with the old platform. But Facebook’s updates include a brand-new authentication scheme for applications, possibly affecting the sort of application attacks first described last year. From a security perspective, I wondered, how much has actually changed?

New Interfaces

To begin, let’s recap some of the new developer tools. First, Facebook is phasing out its old authentication scheme. Previously, applications would generate a session by forwarding clients to a particular Facebook URI. If the user chose to authorize the app, Facebook would forward the user back to the application context, passing along a valid session key (and session secret). The application would then use that session key to generate API requests, signing each with either the session secret or application secret.

Now, Facebook has rolled out OAuth 2.0, a lightweight adaption of OAuth 1.0 and OAuth WRAP. The spec defines several models for authenticating resources, and Facebook uses the Web Server Flow. This process actually involves two major steps. First, the application again forwards clients to a Facebook URI, though this time with a list of specific permissions desired. If the users grants that list of permissions, Facebook again forwards them back to the application with a session key. However, the application must now use the session key to request an access token from Facebook. This step is done directly from the application server, and the request must be signed by the application secret.

In addition to OAuth 2.0, Facebook added new API methods for accessing data. Developers can now use a simple JSON interface to make requests using a valid OAuth access token. At the moment, applications can still interface with the old REST API, but Facebook is requiring developers to use the new permissions model (and hence OAuth) starting June 1, and it’s likely all applications will eventually use the new Graph API for data access and publishing.

I’ve noticed another aspect to the shifts in developer resources: Facebook has hardly talked about FBML recently, and the new developer documentation barely references it. The new JSON APIs are tailor-made for JavaScript use, which would only make sense in an iframe canvas application. I’m not speaking with any insider knowledge, but based on several recent observations, I expect Facebook to eventually deprecate FBML-based apps and shift developers entirely to iframe canvas apps or external websites. (The new, JavaScript-friendly interfaces unite methods used for canvas apps and external sites that previously worked with the Facebook Connect SDK.)

Security and OAuth

While the original OAuth spec has been around for some time, Facebook’s David Recordon helped write the new version, and the first draft came out right around the time Facebook announced their implementation. Consequently, OAuth 2.0 is a rather young protocol, and it’s still under development. I personally find it disheartening that a protocol handling third-party authentication for the personal data of 400 million users has a section entitled “Security Considerations” that still only contains the note, “Todo.” Why would security be an afterthought in this arena?

Facebook’s implementation does have one significant strong point, though. The two-step flow they use makes it essentially impossible to forge a request for an access token. While you may be able to hijack the first step in authentication, getting a usable access token requires the application secret, and if you have that code, you’ve already broken the application itself.

Unfortunately, the benefits end there. While I’m not yet aware of any new vulnerabilities presented by OAuth replacing the old system, using OAuth does not affect many of the previously described application attacks.

Security and Facebook Applications

In fact, attacks on applications will likely get much easier under the new setup. First, since Facebook is pushing developers towards HTML-based applications rather than FBML, exploiting cross-site scripting (XSS) holes will be simpler. Taking advantage of an FBML app requires several tricks, but in a regular HTML context, one can simply insert JavaScript and go.

Second, while the new APIs make requests easier for developers, they also make cross-site request forgery (CSRF) easier for attackers. Since OAuth only handles the initial authentication, once an app has valid session, XSS attacks can hijack that session and issue requests back to Facebook using the app’s access token. This behavior is essentially identical to previous attacks, except that now one must use the access token and make Graph API requests instead of using a session secret to make REST API requests.

Of course, executing such an attack requires an XSS vulnerability in the application to start with, and one may question how common that scenario will be in practice. If my past research is any indication, the chances are very high. Last September I published a series of posts known as the Month of Facebook Bugs which recorded exactly this sort of vulnerability in various Facebook applications. By month’s end, the series demonstrated exploitable holes in nearly 10,000 applications, including six of the top ten apps by monthly active users.

Last month, after reading an article about security on Facebook, I decided to launch the Month of Facebook Bugs Reloaded. My initial plan was to find 30 more vulnerabilities and publish a list of the affected apps, but I’ve since decided against investing the time necessary to build such a list. However, the first afternoon I started working on the project, I found exploitable holes in half of the current top ten applications, specifically: FarmVille, Birthday Cards, Texas HoldEm Poker, Cafe World, and PetVille. Ironically, the FarmVille issue came from the same parameter I’d exploited last year, but this time on a new interface. All of the new issues have been reported for patching.

If you’re not familiar with application attacks, you may wonder how much damage could actually be done. And on this point, things have actually changed slightly. The code I demonstrated last year allowed an attacker to silently and invisibly hijack the session of an application the user had authorized and issue any valid API request back to Facebook. This previously included requests for a user’s private profile information and access to viral channels for spreading links – similar to the more recent vulnerability I described in the Platform itself. Note that the spreading links part could be used for spreading full-fledged malware.

However, Facebook’s new permissions model means that many applications won’t have full access to user information or publishing abilities. Still, any application which does have broad permissions will be a valuable target. But in addition to this change, Facebook has taken much of the previously private profile information and made it public, which means it remains accessible to an attacker, but harvesting is be less of a security issue since it’s now public to begin with.

Looking Ahead

Facebook’s recent updates demonstrated the company’s broad vision for integrating with sites across the Internet. As Facebook expands its reach, though, the surface of possible attack vectors will grow as well. Each site that makes use of Facebook’s powerful APIs will become a target for attackers looking to exploit those APIs. While cross-site scripting problems tend to be rather common on websites, they become even more dangerous when they open the door to compromising a Facebook user’s application session.

Thus far we’ve seen a few attacks against Facebook users that take advantage of applications, but none have been that widespread. I predict we’ll see this change over the next year or two. The size of Facebook’s user base and the trust relationships established on the service make it a very appealing target for attackers, and reduced development friction will likely lead many of them to realize the potential of attacking applications rather than the site directly. Also, the ubiquity of Facebook’s pop-up login windows for authenticating on other websites (often with minimal window chrome) will probably make pop-up imitations a more common scheme for phishing attacks.

Furthermore, other security issues that I’ve not described here still loom for Facebook. I’ve talked before about some of the issues with Facebook’s new Open Graph Protocol previously, and I am awaiting patch confirmation before discussing a few new vulnerabilities in the Platform itself. These problems not only allowed me to replicate the silent data harvesting I’d demonstrated with the issue reported back in March, but opened up new attack possibilities, such as rendering an arbitrary login form with a simple facebook.com URI.

Any site operating at the scale of Facebook is bound to face security problems and increased scrutiny from researchers. But here I’ve chosen particularly to focus on issues with Facebook applications and Facebook-enhanced websites. Attacking Facebook directly can be quite difficult, but insecure applications open up powerful indirect channels, and so far the security track record for applications is not encouraging. That track record could become even more important over the next few months as new APIs spread and old security issues persists.