1. I’m definitely an amateur and have much left to learn.
2. If you’re a web developer and online security doesn’t freak you out, you need to wake up.

In the past I worked with a popular forum script and learned about some basic security problems through that experience.  But now I realize how many potential attacks can exist in a site with user-generated content.  I’m also realizing that visions of data portability for social networks are not only complicated by privacy concerns, but security concerns.  A developer has to be extremely careful any time he/she opens a site to content from third parties.

I have in mind a few basic security tips that are once again not new but well worth reiterating that I’ll try to put into some posts soon.  Right now educational endeavors sap most of my time, but that should change in a few weeks.

Intrigued by this new setup, I checked the code to find out what exactly was happening.  Microsoft’s site loads a Facebook iframe that launches a login window.  The Facebook login page then returns a session key to the iframe, which passes it on to Microsoft.  You’re then forwarded to another Microsoft page which lists your friends’ e-mail addresses.

So how does Microsoft get the data?  I’m fairly confident Facebook has an Ajax interface which requires the session key to return results.  It’s possible that another technique is being employed, but an Ajax request seems to be one of the simplest methods to implement, and the code seems to point towards it.  But the request is apparently made server-side, so I don’t have a URI for the interface.  If someone could figure out what URI is accessed, the feature could probably be leveraged by other developers, albeit unofficially.

I do find it interesting that Facebook has allowed Microsoft to use this feature but no one else - not even users wishing to download their contact list.

A commenter on ReadWriteWeb, however, pointed out that the hack appeared even before this month - though I’m not positive this is the same hack that the AP referenced.  Either way, this news story serves as another reminder for developers to check their query string inputs.

You’d almost be right.

A friend sent me a link to the challenge the day Lee posted it, and by the next day I had a plan of attack.  I sent Lee an innocuous Facebook message asking him to take a look at a simple application I’d built.  I didn’t lie - I had thrown the app together a few months before, and it hardly does anything.  But I did fail to mention one detail - I inserted some new code before contacting Lee.

The code would grab any available information on his secret group as soon as he access the application.  I’m fairly certain my method did not violate the Facebook TOS, and since Lee issued the challenge, I took that as permission to access his group’s data.  I wasn’t sure if he would accept my technique as meeting the challenge, since it did require action on his part, but figured I’d give it a shot.

As I said, though, it required action on his part, and to my disappointment he didn’t actually install the application prior to shutting down the challenge.  At that point I went ahead and contacted him to let him know what I was up to, and he graciously installed my application to confirm that the trick worked.  In a way, my “hack” was akin to phishing - I was luring Lee to visit a page that seemed harmless, but actually took advantage of his visit.

I didn’t really accomplish that much, but the initial challenge was simply to read the group’s “Recent News” section, and I did pull that off.  Accomplishing the rest of the challenge would have been far more difficult, and I don’t think my little scheme invalidated Lee’s original point about doing business on Facebook.  Lee has posted our conversation of Facebook messages regarding the hacker challenge, so check it out if you want more of the story.

So what’s the point of all this?  One I’ve been trying to make for some time: Social applications are powerful.  An application on Facebook has access to a wide range of data on Facebook users, especially if the application finds a wide audience.  But since applications are third-party code, they essentially run on the honor system.  While the Facebook TOS bars applications from storing most user data, there is not a practical way for Facebook to enforce or even completely audit this requirement.

Does this mean we should no longer use applications on social networking platforms?  Certainly not.  But while I’m not aware of any rogue social applications thus far, I would not be surprised to see them before too long.  I expect the people behind things like phishing scams to move towards using social networking sites.  Once again, the social graph is both the strength and weakness of a social networking site - it enables many great features, but also presents a wealth of data that scammers and hackers will target.

Consequently, social networking sites need to be vigilant in protecting and informing their users.  Developers need to be careful to find and plug holes in their applications that people could exploit.  (If they read this blog, they may get some free help in the finding part. :)  And users need to maintain a healthy skepticism of giving any site or application access to personal information.

Anyway, thanks to Lee for the challenge and the write-up, as well as giving me a good opportunity to highlight another point regarding privacy and security.

I say “most” because access does depend on the person’s privacy settings - if they have their friend list set to private, this URL won’t return any results.  But if not, you can easily get a JSON list of the names, profile addresses, and networks of a user’s friends.

Personally I don’t see this as much of an issue, since any registered Facebook user would already have access to this data.  But this trick does make it easier to download the list in a simple format, and the list could easily be inserted into a non-Facebook web page without any platform authentication.  I’ll let others judge the seriousness of this one, but leave the details out for now - contact me if you want them.

Update: When I saw that the URL was returning a friend list, I didn’t dig deeper… today I noticed that the URL also lists the applications that a user has installed and the pages of which the user is a fan.  Fans are listed on a page, so this once again doesn’t disclose new information there, but it makes it far easier to access.  With applications things are a little different, as an application page only tells you which friends of yours have added the application - and regardless, the information is once again far more accessible with this technique.  I’m now notifying Facebook of this issue.

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?

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.

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.

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.

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.