Posted by theharmonyguy in Facebook | No comments

Facebook Applications are Now Even More Valuable Hacking Targets

I’ve demonstrated countless times over the past year that cross-site scripting vulnerabilities in Facebook applications can be exploited to make Facebook API requests on behalf of the application. This type of attack, which I called a FAXX hack, enables one to not only post links to Facebook for viral effects but also harvest a wealth of information on victimized users along the way, such as name, date of birth, interests, family members, photos, and so on. However, contact information lay outside the scope of available data.

Until now. Facebook has launched a new Platform feature that enables developers to request e-mail addresses from their users. An unfortunate side effect of this behavior is that Facebook applications have now become more promising targets for online attacks.

Over time, it’s likely that popular applications will routinely request e-mail addresses from users, meaning eventually certain applications could have millions of addresses saved. (Note that Facebook allows developers to store e-mail addresses indefinitely under this new setup.) One SQL injection hole could potentially compromise all of those e-mail addresses. Also, if the application had an XSS vulnerability, one could easily launch a FAXX attack that requests e-mail addresses from Facebook via FQL.

This certainly all depends on several factors, one being whether many users embrace sharing their e-mail addresses with applications. Some may question whether finding an exploitable vulnerability in a popular application would be likely, but based on last year’s Month of Facebook Bugs, I think the odds are not encouraging.

My recommendation to users would be against letting applications have your e-mail address; Facebook does provide a proxy system if you really want messages. But I do hope this new feature will bring more attention to issues of security on the Facebook Platform.

Posted by theharmonyguy in Facebook | 13 comments

Backup or Export Your Facebook Account

Update

This post has been superseded by “An Updated Guide to Backing up or Exporting Your Facebook.” Please refer to the new post for more current instructions and disregard the information below.

Original Post

Last update: 4 Jan 2010, 4:56PM EST

Introduction

Over the last several years, I’ve seen several technology analysts criticize Facebook for not giving users greater control over their data. Many have commented that while it’s simple for data to flow into Facebook, getting data back out can prove much harder. In the ensuing debate, various issues can get oversimplified – after all, Facebook has a business interest in keeping users, and friends create some of the data users may want to export.

But while Facebook provides few official options for users wanting to export or backup their information and activity on the site, they have steadily widened the amount of data available to third-party applications via their API over the last year or so. Consequently, users with a little technical know-how can use the API to download a wealth of information. This makes it entirely possible to create an archive of your Facebook account.

I do not believe anything I’m about to share violates Facebook’s Terms of Service, since I am simply providing tips for users to more easily download information already available to them via facebook.com for their own personal and archival use. The methods presented here do not require any techniques that avoid or work around Facebook’s official APIs.

Among the interfaces developers can use to access Facebook data, one involves sending FQL (Facebook Query Language) queries to Facebook. These FQL statements resemble standard SQL requests against a set of database tables containing user information. If you’re logged in to Facebook, you can execute FQL queries right now by visiting Facebook’s API Test Console and setting the method to “fql.query”.

With that test console, you can request most of your Facebook account information and simply copy-paste the results to a text file for your own use. In my testing, I set the response format to JSON for two reasons. First, I’m more familiar with handling Facebook information in JavaScript, so JSON is an easier format for me to work with. Second, JSON is far more compact than XML, producing much smaller responses and backup file sizes.

I’ve put together a series of 21 FQL queries that together provide a fairly complete backup/export of a Facebook user’s account. Fifteen All but six of these queries can be executed using the API Test Console without any further effort. The others can only be made from an application with certain extended permissions. Developers familiar with creating Facebook applications can enable these permissions using the following two URIs, replacing “ffffffffffffffffffffffffffffffff” with an application’s API key:

• http://www.facebook.com/authorize.php?api_key=ffffffffffffffffffffffffffffffff&v=1.0&ext_perm=read_mailbox
• http://www.facebook.com/authorize.php?api_key=ffffffffffffffffffffffffffffffff&v=1.0&ext_perm=read_stream

After authorizing an application you administer, you can return to the API Test Console and specify the authorized application for making API requests. This allows you to all of the FQL queries via console and not have to worry about creating code to issue the requests. Please note that I make no warranties or guarantees about using this information – I provide these tips merely as a helpful resource to users who are interested in exporting their data. I cannot guarantee this will work for you, and I cannot promise any support if you have trouble getting these tips to work for you.

The 21 Queries

Here now are the FQL queries, each with a short description. For each query, replace 00000000 with your Facebook ID number.

1. Profile information of friends (note that friends may limit this data via their application privacy settings) (Update 3; added “quotes” on 3 Jan 2010): SELECT uid, first_name, last_name, name, pic_big, affiliations, religion, birthday, birthday_date, sex, hometown_location, political, current_location, activities, interests, music, tv, movies, books, quotes, about_me, hs_info, education_history, work_history, profile_url, profile_blurb, family, username, website FROM user WHERE uid IN (SELECT uid2 FROM friend WHERE uid1 = 00000000)
2. Events you have attended: SELECT eid, name, tagline, pic_big, host, description, event_type, event_subtype, start_time, end_time, creator, location, venue FROM event WHERE eid IN (SELECT eid FROM event_member WHERE uid = 00000000 AND rsvp_status = “attending”)
3. Your friend lists: SELECT flid, name FROM friendlist WHERE owner = 00000000
4. The members of your friend lists: SELECT flid, uid FROM friendlist WHERE flid IN (SELECT flid FROM friendlist WHERE owner = 00000000)
5. Your notes: SELECT note_id, title, created_time, content FROM note WHERE uid = 00000000
6. Comments on your notes: SELECT object_id, post_id, fromid, time, text FROM comment WHERE object_id IN (SELECT note_id FROM note WHERE uid = 00000000)
7. Pages you’re a fan of: SELECT page_id, name, pic_big, website, type FROM page WHERE page_id IN (SELECT page_id FROM page_fan WHERE uid = 00000000)
8. Links you have posted: SELECT link_id, owner_comment, created_time, title, summary, url, image_urls FROM link WHERE owner = 00000000
9. Threads in your inbox (requires “read_mailbox” permissions): SELECT thread_id, folder_id, subject, recipients, updated_time, parent_message_id, parent_thread_id, message_count, snippet, snippet_author, object_id FROM thread WHERE folder_id = 0
10. Threads in your outbox (requires “read_mailbox” permissions): SELECT thread_id, folder_id, subject, recipients, updated_time, parent_message_id, parent_thread_id, message_count, snippet, snippet_author, object_id FROM thread WHERE folder_id = 1
11. Messages in your inbox (requires “read_mailbox” permissions): SELECT message_id, thread_id, author_id, body, created_time, attachment FROM message WHERE thread_id IN (SELECT thread_id FROM thread WHERE folder_id = 0)
12. Messages in your outbox (requires “read_mailbox” permissions): SELECT message_id, thread_id, author_id, body, created_time, attachment FROM message WHERE thread_id IN (SELECT thread_id FROM thread WHERE folder_id = 0)
13. Your wall posts (requires “read_stream” permissions): SELECT post_id, app_id, source_id, updated_time, created_time, attribution, actor_id, target_id, message, app_data, action_links, attachment, comments, likes, privacy, permalink, tagged_ids, is_hidden FROM stream WHERE source_id = 00000000
14. Comments on your wall posts (requires “read_stream” permissions): SELECT post_id, fromid, time, text FROM comment WHERE post_id IN (SELECT post_id FROM stream WHERE source_id = 00000000)
15. Your photo albums: SELECT aid, cover_pid, name, created, modified, description, location, size, link, visible, modified_major, type, object_id FROM album WHERE owner = 00000000
16. Comments on your photo albums: SELECT object_id, post_id, fromid, time, text FROM comment WHERE object_id IN (SELECT object_id FROM album WHERE owner = 00000000)
17. Your photos: SELECT pid, aid, src_big, src_big_height, src_big_width, link, caption, created, modified, object_id FROM photo WHERE aid IN (SELECT aid FROM album WHERE owner = 00000000)
18. Comments on your photos: SELECT object_id, post_id, fromid, time, text FROM comment WHERE object_id IN (SELECT object_id FROM photo WHERE aid IN (SELECT aid FROM album WHERE owner = 00000000))
19. Your videos: SELECT vid, title, description, thumbnail_link, embed_html, updated_time, created_time FROM video WHERE owner = 00000000
20. Comments on your videos: SELECT object_id, post_id, fromid, time, text FROM comment WHERE object_id IN (SELECT vid FROM video WHERE owner = 00000000)
21. Groups you’re a member of: SELECT gid, name, nid, pic_big, description, group_type, group_subtype, recent_news, creator, update_time, office, website, venue, privacy FROM group WHERE gid IN (SELECT gid FROM group_member WHERE uid = 00000000)
22. People tagged in your photos (Update 2; added 2 Jan 2010): SELECT pid, subject, text, xcoord, ycoord, created FROM photo_tag WHERE pid IN (SELECT pid FROM photo WHERE aid IN (SELECT aid FROM album WHERE owner = 00000000))
23. People tagged in you videos (Update 5; added 4 Jan 2010): SELECT vid, subject FROM video_tag WHERE vid IN (SELECT vid FROM video WHERE owner = 00000000)

Notes

• These queries produce JSON (or XML) data that can then be parsed by code written to handle them. The results are not in a format (such as CSV) that can be immediately opened as a spreadsheet. If you are expecting files you can easily read and edit, you will probably be disappointed.
• Note that this does not provide you with direct contact information for your friends (e.g. e-mail addresses, phone numbers, etc.) as one cannot access such data via the Facebook API. This is a limitation imposed by Facebook that I can’t get around without breaking the TOS. (Addendum: The URI http://www.facebook.com/friends/?filter=pfp lets you pull up all your friends’ phone numbers, which would be fairly easy to copy-paste.)
• Update 1: A little more investigation reveals that you can save all of your friends’ phone numbers in a JSON format by visiting this URI: http://www.facebook.com/friends/ajax/superfriends_phonebook.php?__a=1 The “payload” parameter lists the phone numbers, sorted by each friend’s Facebook ID number.
• These queries only yield metadata about photos and videos, not the actual files. If you want to backup the photos and videos themselves, you will either need to load them using the URIs in the query results or use a service designed to backup such information.
• I’ve chosen at this point to only include queries for photos and videos you’ve actually posted. It’s possible to request all photos or videos you’ve tagged in, but that starts raising more questions about the type of information you’re saving, as well as creating duplicate results for photos of yourself that you’ve uploaded.
• Not all of these queries return all possible fields for a given FQL table. I have made selections regarding what I thought would be the most useful fields and what would yield reasonable response sizes. While I tried to make each request complete enough to represent a backup of the relevant information, you may disagree with my choices.
• Update 4: I originally said that the query for friends’ profile information could be limited based on friends’ application privacy settings. However, I’ve since discovered that using the Test Console as the requesting application allows access to all information visible to the user. Remember, application privacy settings only apply to applications you’ve not authorized but your friends have authorized. Apparently, Facebook operates as though every user has authorized the Test Console.
• Some of these requests may generate very large responses, so wait a few minutes if the results do not appear right away. In some cases, you may need to limit requests (i.e. adding “LIMIT 1,500″ for the first 500 results, “LIMIT 501,1000″ for the second 500, etc.). I tested the first query against an account with about 700 friends and did eventually receive a response using the Test Console, but it was about 1.2MB of data.
• In my testing, the responses to these queries were complete, with one apparent exception. The query for comments on wall posts seemed to include only recent comments. I haven’t investigated the issue much yet but will post any updates if I find more information on the issue.
• Please feel free to send questions or feedback to me (my e-mail is theharmonyguy on Gmail), but realize I may not be able to provide technical support if you’ve never used FQL or worked with JSON data. This is not a general solution for non-technical users by any stretch, but it at least provides an option for backing up Facebook information that’s more complete than other methods I’ve seen elsewhere.

Posted by theharmonyguy in Facebook | 12 comments

10 Basic Concepts of Facebook Privacy

1. Your name, your profile picture, your gender, your current city, the networks you’re in, who you’re friends with, and the pages you’re a fan of are available to anyone. These are known as publicly accessible information (PAI). You have no control over this.
2. Any other piece of content marked visible to “Everyone” in your privacy settings is available to anyone. You have control over this.
3. Any Facebook application or web site using Facebook Connect that you visit can access your PAI and content marked visible to “Everyone” in your privacy settings. You have no control over this.
4. Any Facebook application you log in to or web site that you connect with your Facebook account can access all of your profile information (except for contact information), photos, videos, notes, events, groups, links, and notifications, regardless of your privacy settings. You have no control over this.
5. Any Facebook application your friends log in to or web site your friends connect with their Facebook account that you have not also logged in to or connected with can access your information and content based on your application, profile, and content privacy settings. You have control over this.
6. Any wall post a Facebook application or web site using Facebook Connect makes on your profile is visible to anyone who can view your wall. You have no control over this.
7. Any change to profile information or feedback on content will generate a story on your wall visible to anyone who can also access the information or content. You have no control over this.
8. Profile information, photos, videos, and notes are visible to other users based on your profile and content privacy settings. You have control over this.
9. Events you’re invited to are visible to other users who can also view the event. You have no control over this.
10. Past status updates and links are visible to other users based on the privacy setting used when posted. You have no control over this.

Posted by theharmonyguy in Facebook | 39 comments

Easily View Hidden Facebook Friend Lists

Amid all the festivities of the Christmas season, the time off from other responsibilities has given me some more time to pursue one of my hobbies: hacking. (Or at least trying to hack – much of what I do would probably not be considered true “hacking” by many.)

Lately I’ve demonstrated how various data on Facebook, such as photo albums and events, can be accessed by anyone when most users would probably think otherwise. You can now add friend lists to that category of data.

You may recall that when Facebook rolled out their new privacy settings, many analysts complained about the list of who a user had “friended” becoming part of what Facebook classified as Publicly Available Information. In response, Facebook added a setting to remove the lists from a user’s profile, a move that seemed to quell some of the criticism.

But Facebook also made one point clear about friend lists: “This information is still publicly available, however, and can be accessed by applications” (Source: CNET). Since Facebook still considers friend lists to be PAI, I do not consider the details I’m about to publish a vulnerability and therefore feel free to disclose them.

Replace USERID in the following URI with a Facebook user’s ID number (e.g. Mark Zuckerberg’s is 4) and load the URI: http://www.facebook.com/ajax/typeahead_friends.php?u=USERID&__a=1 You’ll see a chunk of JSON that includes a list of the user’s friends, including names and profile links. The list is sorted by friends’ ID numbers. By the way, you don’t even need to be logged into Facebook for this trick to work. (Interestingly enough, I had come across a similar technique years ago, forwarded details to Facebook, then forgot about it; I wonder if this would have worked even prior to the new privacy controls.)

Once again, if you’re using Facebook, make sure you understand what information is available to everyone. (And have a merry Christmas! :)

Posted by theharmonyguy in Facebook | 5 comments

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.