Social Security 102: Client-Side Code

Second in a series.  First post: Query Strings

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?