Facebook Security Hole #1

This is the first post in a series detailing the security holes I find in FBJS. Hopefully others will find this info useful, if for no other reason than to learn some neat JavaScript pony tricks.

Securing Facebook (and JS in the browser generally) boils down to 3 over-arching tenets:

1. prevent execution of arbitrary JavaScript
2. prevent access to the window/global object
3. prevent direct access to DOM elements

Bypassing any of these three access controls gives, at the very least, the ability for a hacker to violate someone’s privacy. At worst, an exploit can cause downtime the Facebook service.

The first security hole was the easiest and least interesting hack. It bypasses access control #1 by making use of an old, arcane behavior of the setTimeout method, namely that you can pass a string as the code to execute:

setTimeout("alert('arbitrary JavaScript')", 1);

Facebook (or more specifically Marcel Laverdet) fixed this by checking the datatype of the first argument to setTimeout:

fbjs_sandbox.set_timeout = function(js,timeout) {
  if(typeof js!='function') {
    fbjs_console.error(...);
  } else {
    return setTimeout(js, timeout);
  }
}

Simple enough. As I said, the hacks get more interesting as we progress.

Thus far I’ve found six security holes in FBJS. I’m sure there are many more, it’s just a matter of finding time to find the holes. To Facebook and Marcel’s credit, they are aggressive about fixing the holes that I find. So while I might complain that the approach of sandboxing-plus-code-generation isn’t an acceptably secure strategy, I’m reassured that they take the issue of security seriously.

Please note that I’m posting these “exploits” publicly only after they’ve been fixed. Facebook is doing all the right things to responsibly handle these security exploits. It would be irresponsible and downright mean to publish early.