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 firstname.lastname@example.org.
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.
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.
Posted on 27 July 2007. 0 comments.
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:
Posted on 25 July 2007. 0 comments.