Facebook

From OWASP
Revision as of 01:12, 19 March 2010 by Jmanico (Talk | contribs)

Jump to: navigation, search

Contents

Authors

  • Himanshu Dwivedi (www.isecpartners.com)
  • Ryan McGeehan (Facebook)

Secure Application Development on Facebook

This document provides a basic outline/best practice for developing secure applications on the Facebook platform. Facebook applications are web, desktop, or mobile applications that make use of the Facebook API to integrate tightly with the social network experience.

This document is designed for the Facebook developer, but it can also be used as a reference for non-technical readers. Depending on the reader’s level of technical understanding of security vulnerability classes and the Facebook platform, sections of the document may be skimmed or skipped.

Overview of the Facebook Platform

The Facebook application developer has many choices in how they integrate into the Facebook platform with their application. It is important to understand the basic elements of the platform before diving into the details of Facebook application security, as each method of integration has different security properties. If you are already familiar with the Facebook platform components, feel free to skip this section. There are two main categories of Facebook applications: Platform applications and Facebook Connect applications. Both types of application can use Facebook markup and scripting languages, as well as a REST client to access the Facebook API. Facebook Connect applications communicate with Facebook through crossdomain communication channels. Platform applications communicate directly with the Facebook servers. The following terms will be referenced when discussing Facebook applications:

Application canvas

The application canvas is the page on Facebook servers where an application lives. Application canvas pages are accessed through the apps.facebook.com domain. For example, the application canvas URL for a fictional game called “Goatworld” might look like this: http://apps.facebook.com/goatworldgame/ . The application canvas page will either be Facebook markup language or an external site hosted within an IFRAME.

Canvas callback URL

The canvas callback URL is the file or directory on the developer’s application servers where the application files are hosted. Facebook proxies the content from the canvas callback URL to the application canvas page.

Post-Authorize callback URL

The callback URL is a page on the developer’s servers which is pinged by Facebook each time a user authorizes the application. Platform applications Platform applications run in a sandbox and are accessed through the application canvas page. There are two types of platform applications that use different methods for sandboxing, including FBML and IFRAME.

FBML

Applications written using the Facebook markup and scripting languages instead of the traditional HTML and JavaScript. When a user accesses the application canvas page, the Facebook proxy pulls down the FBML from the application servers and translates it into HTML before rendering in the user’s browser. It follows that the application code runs in the apps.facebook.com domain. These applications can access Facebook user data directly using FBML, but may also make calls to the Facebook REST API servers.

IFRAME

Applications that are written using traditional web development languages such as HTML, JavaScript, CSS, and run on the developer’s application servers in an IFRAME hosted in the Facebook application canvas page. These applications cannot use FBML directly, so they tend to rely on components from Facebook Connect, such as XFBML and the JavaScript client library, as well as the Facebook REST API.

Facebook Connect Applications

Facebook Connect applications do not run directly on the Facebook platform, but can access a set of powerful APIs to integrate closely with Facebook. Facebook Connect applications can be web, mobile or desktop applications. Connect applications use XFBML tags (which are similar to FBML) as well as the JavaScript client library, the Facebook PHP client or a Facebook REST client in any language.

Security Goals

The first step in securing any application is to outline the required security guarantees your application needs to make, and then to select mechanisms that support those guarantees. For a Facebook application, the security challenges are slightly different than a regular application. The following is a non-exhaustive list of important items that a Facebook application developer has to keep in mind when thinking about security:

Protect access to the Facebook user account

When a user authorizes your Facebook application, they have permitted your application to obtain access to their Facebook account. The application is granted read access to profile data, friend information, and photo albums. The application can also be granted write access to the user profile, status updates, notifications, and the ability to send emails to the user, when the user grants the application the privilege to access restricted Facebook APIs. The application must be as resilient as possible against attacks which could compromise the application's access to a user’s Facebook account through the trust the user has granted the application.

Respect the Facebook privacy policy

In order to respect the user’s trust in your application, as well as to keep your application from being removed by Facebook, it is very important to adhere to Facebook’s privacy guidelines. Facebook denotes what user data is allowed to be stored by your application and for how long. When you do store Facebook account data, use sufficient access controls to guard this data from anyone but the legitimate, authenticated user. More information about privacy and storable user data can be found here: http://wiki.developers.facebook.com/index.php/Understanding_User_Data_and_Privacy http://wiki.developers.facebook.com/index.php/Storable_Data

Protect application-specific user account data and state

Make sure you understand the differences between how Facebook applications and traditional applications approach authentication, authorization, and access controls. The application relies on Facebook to tell whether a user has been authenticated, as well as other information about the user’s session. It is your responsibility to ensure that this information has not been forged or tampered with, before calling Facebook APIs or returning Facebook data for the user.

Protect against common web application vulnerabilities

Protect against common web application vulnerabilities that put application specific data and servers at risk. The Facebook sandboxing of platform applications can sometimes be confused as a protection mechanism for the application. However, Facebook sandboxing only provides protection to Facebook servers. Application servers can be attacked directly, and the minor protection mechanisms the platform sandboxing provides can sometimes be bypassed. It is therefore just as crucial to guard your Facebook application against the same common vulnerabilities you would in a traditional application.

Maintain confidentiality and integrity guarantees when integrating Facebook with HTTPS sites

When integrating an HTTPS site with the Facebook platform it is important to maintain the confidentiality and integrity guarantees offered by the protocol, in spite of the fact that Facebook does not serve its own content over SSL. The application canvas page is not served over SSL, which implies that it is impossible to provide support for SSL communication in an FBML application. Facebook Connect does provide support for SSL. This will be important to take into account when deciding on your method of integration with the Facebook platform.

Important Rules to Follow

Common Vulnerabilities and Protections