I am currently examining the Facebook Platform as a case study on the security of mashups. I am a senior at the University of Virginia and this research is part of my thesis project; Professor David Evans is my advisor. My homepage is located at www.cs.virginia.edu/felt and I can be contacted at felt@virginia.edu.

Facebook patched the XSS hole last night. The flaw was located in the fb:swf tag, which is the FBML tag that allows for the embedding of a Flash swf file. In order to prevent people from auto-playing annoying swfs with animation or music, an image is substituted for the swf until a profile viewer clicks on the image link. Facebook allowed you to put a style tag on that image, and that style tag was only being stripped of special characters (and not JavaScript references).

I provide a code example of the flaw and more specific details in the uncensored version of the white paper.

The fb:swf tag was an all-around mess before. In addition to the unchecked field, they weren't mirroring or proxying the image request. This meant that every time a user loaded a profile, both the viewer and the profile owner were identified to the third party because of the image request (IP of the viewer and referral URL of the profile owner). They fixed this at the same time they patched the hole.

Posted on 16 August 2007. 0 comments.

Although the Facebook XSS exploit is interesting on its own in a technical way, cross-site scripting vulnerabilities are fairly common. More serious is the design flaw that allows the vulnerability to be widely used. Once a vulnerability has been found on the Facebook site, there are no limits on what the attacker can do. Hidden form IDs can be harvested for any form. (Notably, one of these forms will submit a charge to a user's credit card.)

This makes me question the decision to insert third-party code (in the form of application gadgets) into the context of a profile. Although the third-party content is being parsed before being inserted, lex filters are rarely perfectly applied. It seems that it would be trivially simple to isolate profile code in an iFrame to sandbox any potential parsing oversights.

These issues extend beyond Facebook; the setup of the Facebook website and Facebook Platform are by no means unique. More and more websites are adopting similar third-party aggregation schemes to allow users to add additional content and functionality to their pages.

Posted on 28 July 2007. 0 comments.

Facebook was notified of the vulnerability this morning. They responded promptly, although they disabled my demo account. I wrote up the details of the attack in a white paper. This version of the paper explains the circumstances that make the attack possible and outlines what I did to craft the attack but omits the location of the actual XSS exploit. (Once I am certain the hole has been patched I will release the uncensored version.) The following is a sketch of the attack.

1. The potentially malicious code is injected into the user's profile. This calls an XML sheet containing JavaScript, which Firefox loads. (Alternately, this would be done in Internet Explorer using the expression() tag.)

2. The JavaScript is now executing in the context of the profile page. It inserts style sheets to change the appearance of the profile.

3. The JavaScript gets the user ID of the viewer by searching for the appropriate profile.php?id= link. It also gets the secret form ID (which is used on every form for the same user).

4. The JavaScript inserts (potentially hidden) iFrames into the profile. The iFrame(s) point to PHP scripts on the attacker's external host and pass the script the secret form and user IDs.

5. The PHP script uses the secret form and user IDs to POST forms in the iFrame. Since the viewer is logged in to Facebook, the submitted forms will have the proper session information attached to them. (This is session surfing/forging.) Any form performing any action on Facebook can be submitted this way.

Here is a screenshot of how I modified my fake Facebook profile (clicking on the image will bring you to a full screenshot). Also, you may be interested in the movie in the previous post.

If Facebook were to begin generating new form IDs for every page, an extra step would be needed: the page with the form would have to be loaded, searched for the form ID, and then the form submitted in a new iframe. This would be possible because the new iframe will be from the same origin (Facebook) as the malicious JavaScript (executing in Facebook's context). [Thanks to Collin Jackson for pointing this out.]

Posted on 27 July 2007. 0 comments.

Two days ago, I found a new cross-site scripting vulnerability in Facebook. A tag is not being properly sanitized, and I was able to inject JavaScript into a user's profile. Using JavaScript, I then altered the stylesheets to change the way my profile looked. I also created two scripts that forced the viewer to add me as a friend (if we weren't already) or write on my wall (if we were already friends).

I created a YouTube video of me demonstrating the exploit. In the video, I am using two browsers. I am logged in under my fake name (A Graham) in Safari and under my real name (A Felt) in Firefox. I then view my fake account with my real account in Firefox to display the attack. I have the attack set up to only work in Firefox so that you can compare the altered Facebook to the normal. (Note: you may want to read the post above this one to get an idea of what is happening, especially if you do not have your sound turned on.)

I will release a white paper with details of the attack soon.

Posted on 26 July 2007. 0 comments.

The Facebook Platform's official page is located at developer.facebook.com. Here, I offer a brief summary of how it works.

A Facebook developer registers his or her application and receives an API key and secret. The key and secret allow the application to connect to the Facebook REST server. (Interaction with the Facebook REST server is handled by one of the available libraries.) All code must be stored on third-party servers. Applications are assigned a Facebook URL (e.g. http://apps.facebook.com/yourapp/) that will point to their code so that the user does not need to leave the Facebook site to access it.

Developers may choose to create either an iFrame or FBML application. The iFrame design is simple: the application's Facebook home page contains Facebook code in the main frame and embeds the third-party code inside the iFame. The Same Origin Policy means that applications in iFrames are isolated from the surrounding Facebook content, which means that the third-party content can run arbitrary code without affecting the security of the main Facebook page.

The FBML mode is slightly more complicated. FBML stands for Facebook Markup Language, which is a collection of “safe” HTML, CSS, and Facebook-specific tags. These applications are parsed by Facebook servers and then included directly into the Facebook context.

Through the API, developers can request information about the user and the user's friends as long as their privacy settings allow it. Additionally, applications can “push” content to a gadget box in a user's profile. The pushed content must be FBML and is similarly inserted directly into the page context.

Posted on 26 July 2007. 0 comments.

For my senior thesis project, I am investigating privacy and security issues related to mashups. A “mashup” is a site that incorporates content from multiple sources. The mashup model is not limited to sharing space on a page, however; it is often coupled with information sharing. An example is Facebook: the relatively new Facebook Platform allows third-party code to be embedded in profiles and provides access to user information via the API. To begin my research, I am performing a security analysis on Facebook as a case study.

I will be presenting the results of this study at the USENIX Security '07 poster session in August. A more detailed explanation of the case study motivation is available as part of the abstract:

Rich technologies such as AJAX and Adobe Flash have popularized the use of the Web as a dynamic and interactive interface. Browsers are increasingly acting as operating systems, with code from multiple sources sharing the space of a single page on the client side. ... The aggregator provides the application with data, and the third-party application provides the user with a relevant, useful feature that the host aggregator lacks. ... In this situation, the aggregator cannot trust the third-party code but must still communicate with it and attempt to police its actions. ... This work examines the implications of this new web security model and presents a case study on the gadget platform adopted by the wildly popular social networking site Facebook (facebook.com). The aim is to use this example to provide insight on the process of creating a secure gadget aggregation environment.

Posted on 25 July 2007. 0 comments.