Months Later, Old Facebook Privacy Problems Remain

I’ve tried. I’ve tried to give Facebook the benefit of the doubt. I’ve tried to look at the positive aspects of their service. I’ve tried to bring attention to issues and wait for solutions. I’ve tried to provide solutions. But tonight, I’m ready to give up on Facebook. After all the privacy and security problems I’ve seen with the Facebook Platform, I have to conclude that you should consider every action you take and all the content you post on Facebook to be public. If that bothers you, stop using Facebook.

Some might contend that this is the Internet we’re talking about – it’s supposed to be public. Partially true, but many web sites provide services intended for private use. I can use the Internet to check my bank account balance, open a new credit card, and contact my doctor. None of those are public activities. While I’m not naive enough to think that any online activity can be considered 100% secure, I can accept services that provide a reasonable level of privacy and security.

At one time, Facebook fell into that category. I used it to communicate with friends about my life and their lives. I exchanged messages, photos, and ideas never intended for public consumption. All the while, I relied on Facebook’s legendary privacy controls to ensure my content reached its intended audience only. Originally, Facebook didn’t simply discourage you from public sharing – it wasn’t even possible. You could hardly even communicate with people who had not approved you accessing their profile.

Eventually, Facebook introduced the Facebook Platform and began shifting priorities. They faced controversies along the way, from deceptive ads to the failed Beacon program. Most recently, they rolled out new privacy settings which many have criticized. In the midst of all these stories, I’ve spent time sifting through both news reports and code to understand what exactly was happening with my data. This started as little more than a hobby, but eventually it became more serious as I made some disturbing discoveries.

One such discovery involved noticing that advertisements in applications were making requests to the Facebook API for user information. The ad network queries were broad in scope and used to target ads more effectively. I first wrote about problematic ads in June of 2008, but the first time I confirmed that ads were exploiting the Facebook API came in June of this year. I discovered that applications were leaking a “session secret” to ad networks, allowing the ads to hijack application credentials and access user data.

Once I understood the power of a session secret, I began exploiting previous cross-site scripting vulnerabilities I’d uncovered to access user information. One of these holes dated back to at least February 2008. This initial work eventually led to the Month of Facebook Bugs, which spanned September of this year. The project demonstrated XSS issues affecting over 9,700 Facebook applications, all of which could be exploited to access user information (FAXX hacks). The list included many top applications, including ones supposedly verified by Facebook.

I’ve seen Facebook claim that they monitor API requests to avoid rogue applications harvesting user data. But after watching ad networks make broad requests for weeks, I had trouble seeing how they were being proactive. Similarly, while Facebook worked to patch all of the holes I reported in September, they would often give developers my contact information for help with the issues, and were quite obviously not actively watching for XSS problems in applications.

But as I said, I’ve tried to give Facebook the benefit of the doubt. When it came to problematic advertisements, Facebook seemed to take some action, and more recently I’d thought the old problems were essentially gone. As for application security, some could argue that it’s not Facebook’s responsibility to monitor application issues. However, with the brand association of the Platform and application XSS holes exposing loads of user data, Facebook owes it to their users to prevent more FAXX hacks from appearing.

I give that lengthy recap to explain what I report next. On day 25 of the Month of Facebook Bugs, I posted a vulnerability in an application called Photos I Love. At the time, it had just over one million monthly active users. The hole remained live for about a week after I first reported it, but eventually it disappeared. Photos I Love now has more than 2.3 million monthly active users.

But it also still has some of the same ads I criticized back in June. The application loads advertisements from SocialCash, and while the ads do not display and profile pictures or names, the code for the ads does load most of the information in a user profile. This code is executed within the context of the page, so the data is not necessarily sent back to SocialCash, but a few bits are definitely sent back, and with a few code changes by SocialCash it could all be sent back. In fact, SocialCash does receive a session secret via referrer URIs, and I’ve repeatedly demonstrated that such a setup allows for the full range of session secret API requests.

Even worse, the application still loads an iframe for SocialReach, one of the first ad networks banned by Facebook. The SocialReach iframe doesn’t actually display any ads, but it does load code with a session secret that makes broad API requests to Facebook. Fortunately, these requests currently fail, likely due to a mishandling of the session secret, but once again, a few code changes by SocialReach would start the data flowing again. Finally, the session secret is also leaked to affiliate marketer Gratis Network via referrer URIs.

After these rather appalling discoveries, I poked around Photos I Love a little more, and within minutes found another cross-site scripting vulnerability that could be exploited to hijack application credentials and access user information. I’ve found several FAXX hacks in applications since September, and the Facebook Platform Policy Team even asked once if they could copy me on e-mails to developers so that I could confirm patches directly. I wrote this in reply:

I don’t mind you cc’ing me on e-mails to developers, but I couldn’t make any guarantees on how much time I’d be able to invest re-checking holes or helping developers out with details. I view these reports as a courtesy, and try to provide enough details for you to verify where the vulnerabilities occur. Again, I don’t mind helping and am not trying to hurt anyone, but I’m also doing all of this as volunteer work and have other projects that take priority. And while I don’t want to sound rude, if Facebook were really concerned about XSS holes in applications, why not look for them in-house? I think the Month of Facebook Bugs report demonstrated how common such issues are, and that was mostly from me spending a few hours poking around various popular apps.

Cross-site scripting issues are a problem in any application. But when they occur in a Facebook application, they compromise Facebook itself in a very real sense. Yet if the Month of Facebook Bugs is any indication, XSS is widespread on the Facebook Platform. And while I noted in September that applications may include vulnerabilities besides the ones I posted, this second hack of Photos I Love gives firsthand evidence.

All of these issues lead me to conclude that Facebook values public sharing and advertising dollars more than users who want to communicate more privately. The content you post and the actions you take on Facebook are at times more easily accessible to applications, advertisers, and injected code than to your own friends. Perhaps those who want to broadcast publicly or use free social games are fine with such an arrangement. But it’s certainly not the Facebook I signed up for.