Even More Facebook Bugs

Facebook allows applications to request “extended permissions” – the ability to perform actions not normally allowed for applications, such as updating a user’s status or adding photos to their profile. In the past, these were limited and not used all that often, but more recently several applications have been adding novel uses that require extended permissions.

Once I finished up with the Month of Facebook Bugs project (the full report is coming along and should be posted today or tomorrow), one item on my to-do list was checking how granting extended permissions worked in practice. I’ve noticed cases before where an application would request one extended permission and be granted several.

But this morning, I noticed a friend’s status was a message about taking a quiz (an application built using Quiztacular), along with a link. Since this wasn’t the usual feed story, I checked out the application myself, and sure enough it updated my status – without ever requesting extended permissions.

Further investigation revealed that it had been granted the following extended permissions anyway: Status Update, Add Photos, Add Videos, Create Notes, Share, Stories, and Publish to Streams. I then tried installing several other new applications, and each time I authorized one, it would then automatically appear under each of these seven extended permissions. (You can check which applications have extended permissions here.)

I first noticed this issue a little over an hour ago, and sent an e-mail to my contact at Facebook after confirming the issue. I just did another check and the bug is still present.

While investigating that bug this morning, I also came across another surprising aspect of the Facebook Platform. I visited one application page that did not require authorization when first loaded. (Note that this is not unusual – if an application page does not request any user information, it can load as if it were a normal web page.) The page then brought up a typical Facebook pop-up requesting to post a story on my wall about the reward I’d been granted. Intrigued, I clicked “Publish,” and was then forwarded to a page requesting I authorize the application so I could use my reward in actual gameplay.

I checked my profile before authorizing the application, and to my shock, the feed story sat at the top of my wall, complete with pictures and links. At first this may not appear to be a problem, as the application did not gain access to any of my information and I had to give my approval to post the story. But those familiar with previous posts on this blog will recognize the danger of clickjacking. One could easily build a rogue application page that requests a feed story, load it in an invisible iframe, and with one click users would publish a story that could easily include malicious links.

I trust that Facebook will patch the extended permissions bug (which brings back memories of #Twitbook) quickly, and I would hope that they would address the serious danger of the story publishing setup. But I’m not holding my breath on the latter, given Facebook’s track record with this sort of issue. (And on that note, why did the blogosphere take Twitter to task over clickjacking, but has yet to notice Facebook’s complete lack of clickjacking protection?)

Update (Oct. 8): I got word about three hours ago from Facebook that a fix was being pushed for the first issue posted here (the extended permissions bug). I just checked and can confirm the patch: Applications no longer receive extended permissions on authorization, and the applications that had been mistakenly authorized no longer have those permissions. Good work, Facebook.