One item in the report, though, concerned data retention by Facebook.  As TechCrunch describes:

The organization and Commissioner’s main concern is that Facebook provides confusing or incomplete information about its privacy practices, like not giving users to opportunity to complete wipe out their accounts instead of merely deactivating them. Stoddart also criticizes Facebook’s policy of indefinitely keeping the personal information of people who have done just that.

Commissioner Stoddart is not the first to raise this issue, as it’s been a subject of debate for some time.  However, I have not heard many people discuss a related aspect: data retention by third-party applications.

Unfortunately, with the way the Facebook Platform is currently structured, applications receive no notification when a user removes an application’s access to their data or shuts down their Facebook account.  Consequently, an application developer has no way to determine when a user has “uninstalled” the application, and thus for most applications, data retention lasts forever.  You can see this in action by removing an application then later authorizing it again: all of your data generated within the application will likely remain.  For some applications, this data continues to be accessible to other users even if you’ve uninstalled the application.

And this is not simply a Facebook problem.  From what I understand so far, the same issue applies to OpenSocial platforms, such as MySpace.

Granted, there’s not simple solution to this problem, but as concerns grow over the amount of data shared on social networking sites, third-party data retention policies will have to enter the discussion at some point.  One can argue that each application developer is responsible for their own policies, but most applications probably have no policy, and lack of notification on uninstall makes any policy difficult to implement.

Update (8/26): Upon further research, I discovered that I was quite incorrect with this blog post; my apologies to Facebook for making an erroneous statement about the Facebook Platform.  Facebook does, in fact, allow developers to set a post-remove URL which is notified when a user removes an application.  Apparently my experience has mostly been with applications which do not take advantage of this feature, meaning the issue primarily lies with application developers, not Facebook.  I do wonder how many applications actually remove data upon uninstallation.

In this post, I’ll both detail the iLike on Ning hack and raise a question about web development in general.  This particular hack makes me wonder about some larger security issues.

In the early days of OpenSocial, I didn’t have many platforms to test on.  After working with Plaxo, I turned to Ning, where I found a public site using the iLike application.  Most of the gadgets available at the time did not store any user-specific data, so iLike was one of the few that even could be hacked with any significance.  I started browsing through the iLike code to see if I could change the playlist.

I had learned from working with Emote that OpenSocial applications operated in the context of an owner and a viewer.  For instance, if you looked at my iLike playlist, you would be the viewer (you’re the one accessing the data) and I would be the owner (I’m the user who actually controls the data you’re seeing).  If you view an iLike playlist where you’re not the owner, you shouldn’t be able to change any data – only view it.

OpenSocial applications are embedded using an inline frame, so to work with the application’s code, I copied the URL of the iframe and opened it up in its own tab under Opera.  (I happily use Opera for nearly all of my daily browsing, and highly recommend it.)  Furthermore, much of the code for an OpenSocial application is client-side JavaScript, meaning it’s easily viewable within a browser.  While digging through the iLike application’s code, I found a few lines of JavaScript which set variables for owner and viewer to a JSON string of user data.

When viewing the source code of a page in Opera 9, you can also change the code.  After editing, clicking the “Apply Changes” button will then reload the page with your code modifications.  This feature was designed for developers in debugging their sites, but it works for any web page.  More on all this in a sec.  Anyway, I copied the JSON data for the owner and and pasted it in for the viewer data as well, essentially tricking the application into thinking that the owner of the playlist was the person currently accessing it.  A few more code tweaks were necessary to complete the spoof, but eventually it worked and I could modify the playlist at will.  Ning has since added some more authentication to the mix, but I recently had success using the same technique to edit JavaScript in a Facebook application.

Now, the bigger question here, and one I can’t really answer at this point, is the security implications of client-side code in social applications.  From what I understand, the ability to edit the client-side code of a page is not limited to Opera, as I’m fairly certain Firefox extensions can accomplish the same task.

In the past, much of the business logic for web-based applications happened server-side.  If you edited the client-side code of, say, an ASP forum script, you’d just be playing with static HTML and wouldn’t get or set any new data within the application.  But since the rise of “Ajax” scripting, JavaScript is the new CSS, and many developers are realizing its potential.  This had led to web-based applications which are written mostly in JavaScript, often dynamically interfacing with a server-side controller.  All of that JavaScript is executed client-side, however, and user-modified code runs in the context of the remote application.

In one sense, modern browsers are allowing what forum scripts have tried to prevent for years – executing arbitrary scripts on a remote page.  But the forums prevented this to protect the user – if a hacker inserted malicious code into a page, an unsuspecting user could unknowingly execute it.  With user-modified code, the user is the one inserting and willfully executing the code – and now the target is the remote application’s data.

OpenSocial seems especially vulnerable to this type of hack, since the interface between an OpenSocial gadget and a host network’s data happens with JavaScript.  In fact, the business logic for many gadgets is written mostly in client-side JavaScript.  Facebook applications generally operate more server-side, but non-FBML applications are not immune, as the recent Top Friends hack demonstrates.

I’ll be quick to add that the threat of this hack compromising a host social network is probably not high.  Newer versions of OpenSocial appear to have added further user authentication that makes it difficult for a hacker to spoof user credentials and thus gain access to, say, profile data on Orkut or MySpace.  Facebook also includes safeguards to prevent an application from getting to data that a user could not normally access.

The problem is that social application frameworks like OpenSocial and the Facebook Platform create another tier of data which can be much more vulnerable.  For instance, while Facebook stores your profile data and friend list, Slide stores the data you create with Top Friends, SuperPoke, and FunWall.  Compromising Slide’s code could give a hacker access to all of that data, as I’ve already demonstrated.  Sometimes the application data can partially mirror Facebook’s data; accessing your Top Friends list gives information about who some of your friends are, regardless of whether your Facebook friend list is set to private.

Granted, most of the data stored by third-party applications at this point is fairly benign.  But that could change as developers come up with new ideas.  I could foresee an application with premium features storing credit card information, for instance.  And if users trust a host social network, they’re likely to trust the third-party applications on that network – and those applications may be less secure.

So what’s the main lesson for developers here?  Keep in mind that any client-side code you write is visible to the user and susceptible to changes.  (Always – at one point Compare People used a JavaScript compressor to obfuscate their code, but it didn’t take long to undo.)  Don’t rely on client-side code to plug security holes – an enterprising user can remove those plugs.  Make use of server-side checks to ensure that application requests are legitimate.

And I’ll add that I’d be interested in seeing other developers comment on the larger security issues here.  I’m still not sure about the full security implications of up-and-coming technologies, such as Facebook’s JavaScript library or new methods for application data storage.  How much of a danger do client-side web applications really present?

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): http://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.

Initial hack: 20 minutes

Vulnerabilities:

• Able to access listing of friends for any user and limited personal information about these friends
• Able to add and remove playlist tracks for any user

Coverage: TechCrunch

Progress:  Ning and iLike have both been notified.  Ning has replied and stated they are working to fix the issues ASAP.

Update: First “vulnerability” not a vulnerability at all; I’m new to Ning so didn’t realize the data was already available via JSON.  Ning has made some updates to fix the iLike issues; haven’t tested them yet.

Update 2: On November 14 I tested my hack again, and Ning seems to have plugged the hole.  Good work.

Initial hack: 45 minutes

Vulnerabilities:

• Able to change current Emote status for any user
• Able to access Emote history and current status for any user
• Able to insert HTML, including JavaScript, into Emote pages

Coverage: TechCrunch

Progress: Plaxo has removed Emote from their whitelist.  As of Nov. 6, Emote remains unpatched.