I uncovered a way to run arbitrary Javascript within Facebook Applications while looking through the open platform source. I reported it to Facebook, and they’ve now fixed it, so here’s the details.
1 – Load up Internet Explorer (tested on 7.0, but should be valid on other versions, but not on Firefox or Safari)
2 – Go to the FBML test console at http://developers.facebook.com/tools.php?fbml . This tool allows you to preview how your app’s HTML will work after Facebook has run it through its security system.
3. In the large box, copy and paste the following line:
<input type="text" onfocusin="alert(‘foo’);"/>
4. Click on the Preview button below the large text area
5. You should now see an empty text box appear below "Facebook FBML Test Console" on the right-hand side of the screen
6. Click on the text box
Result: You should see an alert box appear containing the text "foo".
Why
is this significant?
Facebook carefully designs its applications system
to restrict Javascript to a very small set of safe functions. With full
access to Javascript, app developers can access all of the information
in your profile, can trigger actions such as mailing friends or adding
applications without permissions, and generally cause mayhem. The code
above just shows an alert box, but it can run any code you want, since
it’s not recognized as Javascript by Facebook’s security screening code.
How was this discovered?
I was looking through the recently
released Facebook Open Platform source code, and noticed that only a
small number of event attributes were being checked for in lib/fbml/wrapper.php. I had a
security bug in some of my own code that was caused by not catching all
the possible attributes, so that made me suspicious that their
production code might miss these too. Microsoft in particular has a
large number of little-known attributes for Internet Explorer
documented here: http://msdn.microsoft.com/en-us/library/ms533051(VS.85).aspx
I tried a few at random in the FBML console, and discovered that
onfocusin wasn’t scrubbed. It’s likely that more of those from the list
are missed too.
As I know to my own cost, it’s a massive
headache to catch all the possible ways of hiding a script within HTML.
I’ve spent a long time staring at the cross-domain scripting (XSS)
cheat sheet at http://ha.ckers.org/xss.html
which documents all the possible ways of fooling a parser, it might be
a good idea to test some of the additional methods they specify too.
How did Facebook respond?
The good news is they fixed the problem a couple of days after I reported it. It took a lot of work to find someone to approach, they don’t have any apparent process for this which is worrying. Instead I just trawled through their blog until I found someone who’d posted about security. He sent me an initial reply asking for more details, but then didn’t respond any further to my emails. All in all, not a very professional setup, they could learn a lot from more established companies. Even Microsoft has a program designed to help people report security issues! Now they’re responsible for a lot of sensitive personal information, they need to think very carefully about security.
Pete Warden's blog 