Posted by theharmonyguy in Facebook | 2 comments

Microsoft’s Facebook Export

Uno de Waal noted yesterday that Microsoft’s new contact exchange system lets you export e-mail addresses from Facebook, a feature not available to other developers and not available in any other form to users.

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.

Posted by theharmonyguy in Facebook | No comments

News: Facebook Private Photos

When I checked TechMeme this morning (yesterday evening was rather busy), I discovered a reminder that even a large site like Facebook is susceptible to the sort of query string problems I’ve discussed previously.  Kudos to those who found the hole, and to Facebook for apparently fixing it quickly once it received wide attention.

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.

Posted by theharmonyguy in Facebook, General | 7 comments

SMUG Facebook Challenge

You may have heard about the $100 hacking challenge issued by social media instructor Lee Aase.  You may have also expected me to take a stab at it.  You may have even thought I would win it.

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.

Posted by theharmonyguy in Facebook | 6 comments

Facebook Contacts

Discovered an interesting little trick today, though not one I would classify as a hack or big security risk, though it’s a slight privacy hole.  After reading about an old method for accessing the friend list of a user logged into Facebook (Facebook has apparently fixed this one), I did some poking around.  To my surprise, I found another URL that lets you access the friend list of most Facebook users.

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.

Posted by theharmonyguy in Facebook, General, OpenSocial | 5 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?