- 1 Authors
- 2 Secure Application Development on Facebook
- 2.1 Overview of the Facebook Platform
- 2.2 Security Goals
- 2.2.1 Protect access to the Facebook user account
- 2.2.3 Protect application-specific user account data and state
- 2.2.4 Protect against common web application vulnerabilities
- 2.2.5 Maintain confidentiality and integrity guarantees when integrating Facebook with HTTPS sites
- 2.3 Important Rules to Follow
- 2.3.1 Your Facebook Application secret must be kept secret!
- 2.3.2 Do not hardcode FB application secret
- 2.3.3 Check the Facebook signatures
- 2.3.4 Provide additional CSRF protection mechanisms
- 2.3.5 Validate and perform output encoding of user controlled data
- 2.3.6 Configure restrictive crossdomain.xml policy file
- 2.3.7 Lock down administrative functionality
- 2.4 Common Vulnerabilities and Protections
- 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:
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.
Facebook Connect Applications
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.
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
Before delving into the specifics, consider the following list of important rules for secure development on the Facebook platform. The remainder of this document will provide further detail on the vulnerabilities and protections referred to in each of these rules.
Your Facebook Application secret must be kept secret!
The Facebook Application secret is given to you upon registering your application, and it is used to authenticate requests to and from the application. If the secret is revealed to an attacker then they can forge requests to and from the application. Store the secret in a secure place (i.e. not hardcoded in the source or in source control repositories, such as SVN) and make it available to as few people as possible, such as net ops and dev leads.
Do not hardcode FB application secret
Check the Facebook signatures
The Facebook signatures that are sent with requests should always be checked in order to verify that the request has not been tampered with and was sent legitimately by Facebook. The signature is created by an MD5 hash of the request parameters concatenated with the application secret, which should only be known to the application developer and Facebook. This signature can in some cases also be checked to provide protection from Cross-Site Request Forgery (CSRF) attacks when it is sent in the GET or POST parameters.
Provide additional CSRF protection mechanisms
Provide additional CSRF protection mechanisms especially with Facebook Connect sites. It is recommended to implement a separate CSRF protection mechanism that is designed specifically to mitigate this vulnerability class. In Facebook Connect sites, the signature and parameters are sent as cookie values rather than as URL parameters. Therefore, these sites need additional CSRF protection as the signature will be automatically sent with the request, even if the request was forged by an attacker. This applies to platform applications which make use of features of Facebook Connect. In this case, the signatures will sometimes be sent as request parameters, and sometimes as cookie values.
Validate and perform output encoding of user controlled data
Configure restrictive crossdomain.xml policy file
The crossdomain.xml policy file must be restrictive in order to keep attackers from changing the flashvars passed to the SWF, potentially subverting verification of the Facebook parameters passed. The crossdomain.xml policy file should be as restrictive as possible to allow access only from the trusted domains that are necessary.
Lock down administrative functionality
Keep administrative functionality on an entirely separate domain, preferably available only internally. A common flaw in Facebook applications is that they allow access to the administrative functionality based on a white list of hardcoded Facebook IDs, and is accessible from the same domain as the application. This allows for XSS attacks to have an even more devastating effect and could make it easier to discover the structure of requests for CSRF attacks. Also, because Facebook does not use HTTPS, sessions of administrators may be hijacked and used to access the administrative functionality. Require additional authentication mechanisms for administrative functionality.