Posted by theharmonyguy in Facebook | No comments

Facebook Application History Pages

Rather than post about individual applications, I thought I would go ahead and do a combined post about an issue I keep encountering.  In my post on query strings, I noted that applications with some sort of history page are susceptible to a privacy problem if other people could access the page.  Not only does the history page list communications between the user and his/her friends, such a listing indicates who at least some of the user’s friends are, and some Facebook users have their friend lists set to be inaccessible to non-friends.

As I said, I keep encountering this problem.  To give you an idea of how common it is, here are a few of the applications where I have found it trivial to access the history pages of users with private friend lists:

• SuperPoke
• FunWall
• Super Wall
• Moods

The first has over 400,000 daily active users, while the next two each have over a million.  The fourth has just under 100,000 daily active users, but I’ll note it doesn’t include any information about friends in the history page.  I’ve contact Slide, Inc. twice about the issue with SuperPoke, and frankly I’m quite surprised to see it present in all four of these popular applications.  Perhaps it’s by design, but I think most users are probably under the impression that all of their history with one of these applications is not accessible for people who can’t access their profiles, and that’s simply not true.  Fixing the problem would involve a simple if-then statement to see if someone requesting a history page has sufficient rights the view the information.

The fact that four of the most popular Facebook applications are vulnerable in this regard leads me to believe that many other applications have a similar issue.  Once again, this isn’t a major security hazard, but for some users it can be an important privacy issue.

Thankfully, I’ll add that I have not been able to actually change a user’s data (e.g. posting on their Super Wall) in any of these applications, unlike my original hack of Emote on Plaxo.  I primarily credit Facebook Platform’s authentication setup for this being the case.

Posted by theharmonyguy in Facebook | No comments

Top Friends on Facebook

Date: February 4, 2008

Initial hack: 15-20 minutes

Vulnerabilities:

• Able to access Top Friends information (e.g. the user’s top friends, who the user is a top friend of) for any user

Progress: Slide, Inc. has been notified.

Details: Can you tell I’m playing with Facebook apps tonight?  This hack uses the same kind of technique as the iLike on Ning hack.  It allows one to view a user’s selected “top friends,” even if that user’s normal friend list is inaccessible directly.

Posted by theharmonyguy in Facebook | No comments

Bumper Sticker on Facebook

Date: February 4, 2008

Vulnerabilities:

• Able to add a bumper sticker to profile and make it appear to have been sent by any other application user

Progress: Bumper Sticker has been notified.

Details: Illustrating what I posted the other day, I discovered tonight that I could use a query string hack to add bumper stickers and make them appear to be sent from other users.  Nothing major, just a possible source of embarassment, but once again shows how even popular applications (Bumper Sticker currently has nearly a million daily active users) can be susceptible to such problems.

Posted by theharmonyguy in Facebook, General, OpenSocial | 1 comment

Social Security 101: Query Strings

Perhaps people have wondered where I’ve been… I apologize for the long delay in posting again.  I’m actually still involved in educational pursuits, and studying for finals quickly became a priority after my last post.  I can’t promise how often I’ll often I’ll be on here, but I have continued to keep up with the social networking market and have continued to tinker with a few applications.  I also want to apologize that I never got back to many people about offers they made; all were very appreciated, but none feasible at this time.

I’ve also learned from my last few adventures how much of an amateur I am and that I shouldn’t be too quick to point out potential holes.  Consequently, I’m evaluating potential hacks more carefully to provide the most reliable information possible.

Anyway, I wanted to make good on previous promises and detail some of the previous techniques I’ve used for hacking social applications.  Once again, they’re surprisingly simple, so I thought this would be a good opportunity to remind social application developers of basic security issues they need to be aware of.  You’d be surprised by how many popular applications neglect these issues.

Many of my previous hacks simply came from passing the right query string to an application.  For instance, by examining the code for RockYou’s Emote application on OpenSocial, I found certain URLs that were accessed for performing particular actions.  This means that when you clicked a button to, say, update your current Emote status, the application would send the data by forwarding you to an address like this (fake URL – I’m only illustrating): https://theharmonyguy.com/app/update.php?uid=1234&status=Happy  Each parameter of the query string sent information on the action to be performed.  Amazingly enough, I simply had to change a few parameters, such as changing the user ID number for “uid” to John McCrea’s ID, to accomplish the same action but for another user.  The application never performed any authentication to see if the request was coming from someone logged in with the changed user ID.

This can also become a privacy issue, as I’ve seen on several Facebook applications.  The Graffiti application used to have this issue; best I can tell they’ve fixed it.  To access a table of drawings that people have sent you in Graffiti, you visit this URL: http://apps.facebook.com/graffitiwall/wall.php?to_id=1234 (where 1234 is your Facebook ID).  Previously, changing the ID number to any other Facebook ID would let you view that person’s drawings as well.  The application failed to check your relationship to the person before presenting the data.  Any application which has some sort of history page is susceptible to this problem.

Finally, query strings have long been a source of injection attacks.  This comes from passing data via a query string parameter which gets interpreted by the application as a command of some sort.  A common problem I’m seeing in Facebook applications leads to a new type of injection: inserting FBML into canvas pages.  Many applications, including popular ones, will render messages on a page by adding a query string, such as (again, fake URL): http://apps.facebook.com/app/status.php?message=Your+status+has+been+updated  The problem is that the canvas page then takes the query string parameter and inserts it without any filtering.  That allows a hacker to insert FBML into the parameter, which will then be rendered by the application – I’ve inserted iframe’s into several apps.  I’m not exactly sure how much of a security issue this is, since something like an iframe can’t easily spoof application authentication parameters, but it certainly seems like a problem waiting to happen.  Furthermore, in RockYou’s OpenSocial application, I used this same technique to insert HTML/JavaScript into pages.  Take note: any input parameters that are rendered in a page should be escaped first to avoid injection attacks.

Query strings have been a way to hack several applications, ranging from Emote to SuperPoke.  But hacks like iLike on Ning utilized a different technique that developers ought to be aware of – one I’ll detail in my next post.

Oh, one little bonus before I go… one of my SuperPoke hacks was figuring out how to access all available actions, regardless of “level” or season.  SuperPoke recently introduced pay-only premium pokes, and while they block access to the premium pokes using my technique, all of the free ones still work.  I took that as a sign they don’t mind my little hack (which I did mention to them months ago), so I whipped up a simple application just for fun: Full SuperPoke.  As I say, this is only for fun, not to harm anyone, and if you don’t want to spoil the fun by skipping all the levels, you needn’t bother with it.  But if you’d like to enjoy some new actions, check it out.

Posted by theharmonyguy in Facebook | 3 comments

Compare People on Facebook (Fixed)

Vulnerability:

• The Compare People application on Facebook sends user profile information, such as age, gender, city, ZIP code, favorite music, favorite movies, favorite TV shows, favorite books, “about me,” activities, interests, and political view to Google AdSense when displaying advertisements within the application.

Progress: Facebook has been notified.  Compare People has commented; see below for updates.

More Detail: Today I was checking out my rankings in Compare People and decided to check for any security or privacy holes.  While I haven’t actually hacked it (though I have some ideas), I was quite surprised to discover how much of my profile information is collected and sent to AdSense.  From what I understand, this information is stored by Google, and thus this practice clearly violates Facebook’s TOS in that it 1) shares personal information with a third party without the user’s knowledge or consent and 2) the third party stores information whose storages is restricted by the platform documentation.  The code for Compare People caches this information and information on a user’s friends, but does not appear to store any of the data long-term.  I checked Compare People’s application page and off-Facebook documentation for a privacy policy and never found one, which could be another TOS violation.

Update: Thanks to Naval Ravikant from Compare People for replying and clarifying some things.  First, according to Ravikant, Google does not store the profile fields like location, favorite movies, etc. and only uses them as keywords when generating the ads.  Prior to posting I had researched this feature of AdSense, and best I could tell the info was stored.  But as Ravikant pointed out, “personally identifiable information,” such as a user ID or name, is not passed on.  Finally, Ravikant mentioned that many Facebook applications are employing the same techniques in generating their ads.  I still don’t think transmitting such data to another application without notification or consent from the user would be consistent with the TOS, but Facebook will have to answer that question.

Compare People is disabling the feature until they get some clarification on whether it violates the TOS, and I appreciate their responsiveness.  In any event, this once again reminds users how many ways data about them can be collected and used on the Internet, both with Facebook applications and Google AdSense.

Update 2: VentureBeat received word from Google that they have asked Facebook app developers not to send such information as keywords any more, has stopped using such keywords, and has not received any “personally identifiable information.”