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.