FBConTroller v2.0 was released late yesterday. As the author clearly states, FBController does not, nor can it, hack into a Facebook account. What it CAN do though is to control a Facebook account (write on one’s own wall, others wall, retrieve profile page, retrieve friends list and even attempts to retrieve inbox and send messages) without having to have the password for the account. Instead of the password, it simply needs the Facebook cookie values for an account. As we discussed in my #heweb presentation, once you identify a Cross-Site Scripting (XSS) vulnerability, it is simple a matter to capture a victim’s cookies. As theharmonyguy pointed out last month in his Month of Facebook Bugs, a huge number (9700) of facebook applications are riddled with security holes, with XSS being the most common.
Armed with the list of vulnerable facebook applications, and FBConTroller, an attacker can potentially harvest a huge number of facebook cookies. From there s/he could spam the accounts users/friends, sending them links to other compromised sites or to download malware. If you are an admin of your University’s facebook page/group, be very paranoid about which facebook applications you use, or simply don’t use any at all.
Photo by Aaron Landry
Thanks for the link!
Slight correction, though: Since Facebook runs all applications on the apps.facebook.com domain, an XSS hole in an application would not allow you to grab the cookies for facebook - at least not in any modern browser I know of.
Of course, you can send links to other users with an application XSS hole by using the Facebook API.
Correction to my correction: As Paul pointed out to me via Twitter, an attacker could theoretically change document.domain. But Facebook filters any JavaScript in an application running via apps.facebook, so they wouldn’t allow such code via an app XSS hole, and the attack would still fail.
Paul corrected me that you could actually change document.domain if you could run pure JavaScript on an apps.facebook. But code on that domain is filtered by Facebook, so inserting script that tries to change document.domain would not be rendered.
So, exploiting an application would still not work, but for a different reason. Thanks for the clarification, Paul.
It will be really good if works well according to the user needs
Oh wow! its amazing. I hope that it ‘ll be a very good function to the users. I don’t know about it. Thanks a lot for sharing such a nice post.