May. 28, 2009

Posted by in Facebook | 4 comments

About That Verification…

When Facebook announced the first Verified Apps a few weeks ago, someone sent me a link to the story and suggested I try to hack one.  This week I discovered one that appeared to have some holes, so I gave it a shot.  Not everything I tried worked, but I did discover some pretty interesting privacy issues.  The application does overlook some basic measures to prevent many of my techniques, so it wouldn’t surprise me if there are more holes I haven’t uncovered yet.

The application itself appears to only have one hole so far, but it’s a gaping one.  From my research thus far, it lets me access the photo albums of any user if the album Facebook privacy settings allow it (and by the way, the default settings do).  Rather than try getting photos from a celebrity (I’m just not that kind of hacker), I’m issuing an open invitation to news outlets who would like a demonstration of the hack.  Contact me via e-mail, which is my alias at Gmail, if you’re interested.  This invitation is limited to sites which have appeared on Techmeme in the past year.

But just as interesting as this issue is the privacy problems I found with the advertising used on the application.  I’ve torn apart ads on Facebook before, but I haven’t seen anything like this.  I noticed the app had banners which included friends’ names and profile pics, so I did my usual checking to see how it worked.   I discovered four things I find disturbing.

First, I was surprised to see right in the HTML for the application that when it called for an advertising banner, the iframe URL included my full name, sex, date of birth, age, relationship status, and college information (schools, years, degrees, and majors).  I didn’t really think an application, particularly a verified one, should be passing such profile information to a third party.

Second, I went through my usual process of editing query strings and cookies to see how little information was necessary to pull up friends in banner ads.  Much to my chagrin, providing simply a Facebook ID brought up ads with friends’ names and profile pics.  Note that this worked for people whose friend lists are not public.  Furthermore, the profile pictures were not always the person’s current picture, which led me to believe the ad network was storing such images.  In fact, the images were not even being loaded from Facebook at all – they were images stored on an ad network server.  Social Banners may not have been a TOS violation, but I’m having trouble seeing how this is not one.

Third, one of the ad networks stored my full name and Facebook ID as cleartext in its cookies.  Not a major issue, but still a bit unsettling.

Finally, in watching packets as I tested different techniques, I noticed some calls to Facebook’s REST API.  To my utter amazement, the referrer on these requests was not the application (the calls appeared nowhere in the app’s source code), but an ad network iframe.  The ad network used the calling application’s session information and API key to access the data.  And what data did it request?  I present three API calls the ad network issued (and I’ve checked that they do return the requested data from Facebook):

  • select uid, status, birthday, education_history, current_location, sex,meeting_sex, meeting_for, first_name, name, pic_square, affiliations, work_history, movies, relationship_status, tv, books, music, activities, interests, status, wall_count FROM user WHERE uid = ‘[current user ID]‘
  • select uid, birthday, current_location, sex, first_name, name, pic_square, relationship_status FROM user WHERE uid IN (select uid2 from friend where uid1 = ‘[current user id]‘) and strlen(pic) > 0 order by rand() limit 500
  • select subject from photo_tag where pid in (select pid from photo where pid in (select pid from photo_tag where subject = ‘[current user ID]‘)) and subject != ‘[current user ID]‘and subject != ” or pid in (select pid from photo where aid in (select aid from album where owner = ‘[current user ID]‘)) and subject != ‘[current user ID]‘ AND subject != ” ORDER BY subject ASC limit 500

Does anyone else find this disturbing?

By the way, these are not fly-by-night ad networks – they are used by many publishers.  Some may point out that users can adjust privacy settings to keep advertisers from accessing data (though that doesn’t really apply if the ads reuse application access), or opt out of advertising networks, or not authorize every application that comes along.  All valid points.  But how many users even know about these issues?  One of the primary purposes of this blog is simply to raise user awareness.  And at the risk of beating a dead horse, why does every Facebook application have access to all of this data to begin with?

It honestly frustrates me a bit that users get worked up over legalese in the Facebook TOS but ignore these sorts of privacy issues, which I and others have raised for quite a long time now.  The Facebook Platform has some of the best privacy settings in the industry, but critical flaws in the structure of the Platform seriously tarnish its reputation.  Yet neither Facebook nor its users seem particularly concerned about these flaws.

And yes, I’ve refrained from naming any applications or ad networks in this article.  My purpose is not and never has been simply to embarrass social networking sites and application developers.  Yet many of my previous posts seem to have been ignored by both.  I thought perhaps this time rather than just pointing out yet another set of privacy issues, perhaps I could whet someone’s appetite to become more interested in the larger issues at hand.  My blog has little reach (I’ve only showed up on Techmeme once), so perhaps others with larger audiences can help spread the word.

  1. This is great stuff. I do some FB app poking over at LBT I’ve been investigating some malicious apps recently too, found some other disturbing things I was in the process of writing up. Drop me a line, I’d love to swap notes.

  2. Fantastic research as usual! Like you said…users of social media have no idea in general that they allow by default every FB application to access all of their data. What makes it worse is that users put way too much information in their profiles to begin with…thinking that because their profile isn’t “public” they are safe. We need more research in this area..myself and a few other researchers are working on similar projects, some specifically focused on Facebook applications and Facebook Connect (don’t get me started about FB Connect). Would love to collaborate on this research with you and others.

  3. Hey friend, I’ve been following your blogs religiously for a few months, and I really appreciate what you do. I’m quite interested in privacy issues on social networks, especially considering our organization has recently moved to use the ning platform. Keep up the good work.

  4. Thanks to everyone for the comments – very much appreciated. Joseph and Tom, I’ll try to e-mail both of you soon. I meant to get in touch a while ago but lately been distracted by life. :)

Trackbacks/Pingbacks

  1. Light Blue Touchpaper » Blog Archive » How Privacy Fails: The Facebook Applications Debacle - [...] all of this happen using a packet sniffer in real-time and it’s quite amazing. There’s a great writeup from ...
  2. Social Hacking » Blog Archive » Finally - [...] Social Hacking « About That Verification… [...]
  3. Debunking Facebook’s Statements on Ads | Social Hacking - [...] ads which make Facebook API requests from the SocialReach web site.  These are the same FQL queries SocialReach made ...
  4. Social Media Security » Debunking Facebook’s Statements on Ads - [...] ads scripts which make Facebook API requests from the SocialReach web site.  These are the same FQL queries SocialReach ...
  5. Facebook Taking Action on Application Ads | Social Hacking - [...] the tape.  On May 28th I posted the following tidbit about a Facebook Verified Application: I was surprised to ...

Leave a Reply