UW Computer Security Research and Course Blog

In mid-2007, Facebook launched a free development platform that allows independent designers to create applications that integrate with core features of Facebook. Since then, over 33,000 applications have been made, the most popular of the applications having over 16 million monthly active users. Facebook applications are intended to be opt-in modular extensions of Facebook for which users can voluntarily register. Facebook itself is composed of a collection of applications; many of the features people perceive as emblematic of Facebook (e.g. the Wall, Photos, and Events, to name a few) are actually “applications” in this design scheme, and they are provided by Facebook by default when one registers for the website.

Since its initial launching, 3rd party applications have caused an influx of problems for Facebook and its users. Advertisement-heavy applications spammed users and popular applications cluttered profiles, reducing the usability of the website. In July 2008, Facebook implemented a considerable redesign to reduce the prominence of applications on Facebook profiles. However, applications pose significant security issues that have yet to be addressed.

Assets and Security Goals

• User Privacy. Many Facebook users trust the website with an abundance of highly sensitive information, such as religious and political views, phone numbers, home addresses, and even credit card numbers.
• Facebook Source Code. Facebook itself runs the risk of revealing its source code or security holes by allowing developers to make API calls on Facebook data. Carelessness in the platform could result in ruining essential parts of the site.
• Facebook Reputation. Facebook applications are embedded in the Facebook interface. Even though they are often developed by 3rd parties completely outside of Facebook’s control, users still perceive Facebook to be partly responsible for the applications.
• Facebook Liability. Allowing independent developers to create applications for their website could potentially put Facebook into legal trouble if the developers created malicious applications.

Adversaries/Threats

• Thieves and Spammers. A social networking site as widespread as Facebook contains an abundance of information hackers would love to obtain. Spammers could get a hold of not only emails, phone numbers, and home addresses, but also a list of interests that allow for targeted advertisements. Gift and donation applications often take credit card numbers, which may or may not be secured.
• Stalkers. Facebook is a repository of photos and contact information. Exploiting security flaws in applications, stalkers could indirectly retrieve personal information about the users of the application.
• Government and Schools. Government, schools, and other authoritative figures may use Facebook to look for evidence of “wrongdoings” in the eyes of the authority. While Facebook itself takes measures to protect the privacy of users, these 3rd party applications are usually far less secure, but still have access to the information stored on Facebook such as profile information.

Potential Weaknesses

• Applications have access to the information of users’ friends. When a user installs a Facebook application, the application developer has access to all the public information on a user’s profile – and all that user’s friends’ information. Therefore there is no way to completely opt out of giving Facebook applications your information unless none of your friends add applications. One can edit the amount of information apps can see, but this feature is unknown and hidden away (not to mention unintuitive), and the default options allow apps to access copious amounts of user information.
• Poorly coded/secured applications. Applications can be written by anyone, even programmers with only a cursory knowledge of PHP and SQL, and code is stored entirely on 3rd party servers. Many applications do not have any sort of authentication on their servers when processing queries from their own Facebook applications, something the most novice hackers can intercept. (See Risks for more information).
• Malicious applications. Anyone can make a Facebook application, and Facebook applications provide an environment conducive for convincing attacks. A famous example was the Secret Crush application that led users to download malware onto their machines.
• “Extended permissions” are easy to obtain. Facebook attempts to limit developer’s access to user’s Facebook accounts by default, but developers can request “extended permissions” through simple API calls. Extended permissions allow the application to email the user, send text messages to and from the users, access the user’s data even when they are offline, and other invasive activities. The user must OK these requests, but many times users will accept the request, unsure of what it does. The permissions are also revocable, but again, many users do not know what these permissions are or why they would be revoked.
• No enforced terms of service for applications. Facebook washes its hands of all legal responsibility via its terms of service:
  

  When you install a Developer Application, you understand that … we are not responsible for your use of or inability to use any Developer Applications, including without limitation the content, accuracy, or reliability of such Developer Application and the privacy practices or other policies of the Developer. YOU USE SUCH DEVELOPER APPLICATIONS AT YOUR OWN RISK.

  While Facebook has a set of guidelines for 3rd party applications, Facebook makes no guarantee that these applications will obey the guidelines. This means that if an application stores your personal information indefinitely, sells your contact information, or otherwise abuses your privacy, Facebook will make no action to rectify the situation.

Potential Defenses

Facebook should have legal backing behind the Platform Application Terms of Use. Without legal backing, the document has no power at all.

Facebook could also play a larger role in the development process. Right now, applications are created entirely on the developer’s webspace, and the application queries this “callback url” for the content that should be rendered in the application canvas page. If Facebook hosted databases and webspace for applications, there would be less flexibility in application creation, but Facebook could employ tactics that would help enforce secure transactions.

Facebook could make privacy issues clear to the user. Very few users know exactly how much information applications are allowed to see. When a user adds an application, Facebook warns the user that the app has access to his or her information, but there’s no mention to the user’s friends, even though they too are giving up information.

Facebook could simply require a fee to develop applications. This would deter many amateurs from cobbling poorly designed applications.

Of course, the ideas stated above would be very expensive to implement and annoying for usablity. Instead, Facebook has simple measures in place to help users determine “spammy” applications and safe applications. Facebook recently created an Application Verification Process that essentially gives a seal of approval to applications that pass Facebook’s standards. The seal of approval is expensive, though – the application alone is $375 (reduced to $175 for students and non-profits). It is also not likely that “verified” apps will be tested for robust code; verified apps only guarantee that the intentions are good, not the implementation.

Risks

Perhaps the biggest security risk raised by independent Facebook applications is the quality of code generated by amateur developers. While the platform code itself is fairly secure, literally anyone can make a Facebook application, and often these programmers know very little about basic website security. Many applications do not have any sort of authentication on their servers when processing queries from their own Facebook applications, something the most novice hackers can intercept.

The Moods Application was a notorious example and there is a YouTube video explaining how it could be hacked using Firebug. (The Moods Application has since fixed this security hole, but it is representative of the poor code prevalent on applications.)

While changing your friend’s “mood” is fairly innocuous, one can imagine the ramifications of poorly secured applications. There have been Facebook applications that could register users to vote in the 2008 election and applications that take credit card numbers for donations to charities; even if the intentions of the application developers are earnest, poor code can make these applications a hacker’s goldmine.

Furthermore, these risks are far greater when taking into account that (naturally) not all developers are trying to develop applications in earnest.

Conclusions

Facebook has the ability to make applications more secure and responsible of user privacy. Quite frankly, Facebook does not want to do this. Enforcing security involves a lot of manpower and financial obligation, and it introduces difficult usability challenges. The attraction to developing on the Facebook platform is exactly this abundance of easily accessible private information, and Facebook would lose a lot of its draw by tightening security.

While Facebook applications seem unreliable right now, applications could be even more damaging in the future. Currently the average Facebook user is a college student, but in a few years many of these college students will graduate and obtain jobs. The information being hosted on Facebook now –photos, comments, groups, interests – could be accessible to future employers, business partners, or political rivals. Although Facebook has some provisions to protect users, applications are an easy way to sidestep any security measures put in place by Facebook.