Feb. 11, 2008

Posted by in Facebook, General, OpenSocial | 4 comments

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?

  1. Thanks for testing OpenSocial security.
    In OpenSocial 0.5 there was no security at all, one of the reasons why it was only a developer release.

    In 0.7 which is the version that will go live there is much more security baked into in the specification.

    The fact that makeRequest http://code.google.com/apis/gadgets/docs/reference/gadgets.io.html#makeRequest in OpenSocial 0.7 allows for signed and authentified calls makes these applications more secure.
    Also Caja http://opensocialapis.blogspot.com/2008/01/six-apart-hackathon-wrap-up-and-caja.html will constrain the javascript executed on the client side: it is not a mandatory aspect of OpenSocial but it is recommended for containers to use, and MySpace and Orkut will use it.

    Please chime in the forum if you find holes.

    OpenSocial API Evangelist

  2. Thanks for the comment, Patrick. My main concern with OpenSocial applications is not so much the security of OS requests made to the host social network for information (I’ve noticed some of the improved security in 0.7), but rather pieces of code that send/retrieve data to/from third-party servers.

    For instance, while iLike would get user credentials from Ning or Orkut, the playlist data was stored on iLike’s servers. This is precisely the nature of the Top Friends hack – I’m able to retrieve data that Slide has stored about other users, and since that data isn’t coming from Facebook, I don’t have to spoof Facebook user credentials.

    Granted, Top Friends is a Facebook application, but the point is that any JavaScript-based application is susceptible to this problem. By mentioning my particular concern over OpenSocial applications I wasn’t implying that the platform is less secure than others, simply that its reliance on JavaScript may lead to more application holes than server-side solutions, such as processed FBML applications.

  3. Hi,
    You rise a very good question. Coming from the security industry myself, I know how you feel about these issues. There is a rule of thumb, and not very hard to follow, all security checks, input validations and alike MUST be done server-side, dot. Any check you do on the client is susceptible to an attack. All inputs going to the server, even then ones generated by the client side js MUST be checked as they might be altered.

    And you don’t have to have Opera or a FF addon, it’s as simple as downloading the website, opening the js file with a text editor and resend the form/post/ajax call.

    Nice post! Keep the good work!

  4. The loan are useful for people, which are willing to ground their own company. By the way, that’s easy to get a small business loan.

Leave a Reply