This morning I randomly came across an old article on Inside Facebook that quoted yours truly on application security. In the quote, I described injecting FBML into applications via a query string, though I also noted that I was unsure how serious such an attack could be. One of the applications I had in mind was SuperPoke. Since the Inside Facebook article was published in February of last year, I decided to check SuperPoke once again.
To my shock, not only had the hole not been fixed, it was worse. SuperPoke is now loaded as an iframe instead of an FBML canvas page, and the injection method still works fine. That means one can now use it to inject arbitrary HTML into the SuperPoke iframe. Using this, a malicious coder could easily insert JavaScript (and set or modify cookies) into the page (XSS).
Normally this is serious, but in a Facebook application, it’s even worse. Since the script would be embedded in an application iframe, it would be able to make FQL queries using the application’s session information, just as I previously discussed SocialReach and SocialCash doing. In fact, such script could probably use just about anything in the JS API. I’ve already tested building URLs for FQL queries via the REST API.
Did I mention that SuperPoke is a Facebook Verified Application?
Granted, this type of attack requires a user to make a click, but any security researcher knows that’s not difficult. And since the JavaScript loads silently, the user would only see a normal SuperPoke page appear and not realize anything was amiss. As always, e-mail for details. I thought it would not be wise to release details publicly given the significance of this attack, though as usual they’re not that hard to figure out.
Update (6/19): I’ve put together some proof-of-concept code that exploits this XSS vulnerability. Loading a particular SuperPoke URI executes a remote script which then retrieves user data via the Facebook API. The API call to Facebook appears to come from the application page. Details available upon request.
