Wednesday, December 10, 2014

Posted by Paulos Yibelo
1 comment | 8:41 AM


Normally, this bug is a Second-Order-Injection against Facebook mobile that turned out to result XSS on another server (Facebook Studio).

This is caused because of improper user input parsing. First, I noticed doesn’t use Linkshim (malicious link detection system for Facebook). When I saw that, I immediately wrote to Facebook about it. But then I realized, this is not exploitable because it fetches the URL’s from My Facebook profile. Take: is a site blocked by Linkshim.

Meaning, if I add “” as my website on Facebook, it will be fetched to my Studios account. And thus, there needs to be no linkshim because it was first checked on Facebook.

As per my understanding, Linkshim uses a list of sites to identify if the site is malicious or not. So bypassing basically includes cheating the linkshim into thinking our site is not included. As always, I started with case-sensetivity bypasses, hoping, if is blocked, to bypass it with or something like that. But they weren’t vulnerable.

Then I tried URL encoding. There is a value in html called shy. That basically, well, shies elements. This tag can be used in href elements. So <a href=”evil&shy;” >X</a> is equvallent to so all I had to do is add evil&shy; as my website using the mobile interface of Facebook (since the main site sends requests to verify, and the mobile version doesn’t)

So when Facebook studio fetches my URL from my Facebook profile and add it in href tag (hoping it is a safe link checked by Linkshim, and it is), it will become “<a href=”evil&shy;” >X</a>” when clicked redirects to, which is considered a linkshim evasion.

Seeing the source, I then wondered why &shy; still itself and not encoded. So I tried my chance with”><script>alert(0);</script> but that link become

<a href=””” target=’_’ >X</a>
It basically means, the inputs < , >, /  and anything following them is filtered. So I tried event handler XSS’es since quotes aren’t blocked with payloads like 

So that will be rendered as
<a href=””onmouseover=”alert(1); //&shy;.” target=’_’ >X</a>
The bad news is I can’t make it self-executable even using autofocus and onfocus because it is href attribute. So I tried ways of making this self-executable. Then, I  use CSS to make the font very big, so it will fill the screen. So onmouseover will automatically get it triggered because the mouse will be all over it. Note: since it’s a URL for Facebook, no spaces were allowed. 

That was the final payload I added to my Facebook account, as my website. The problem with Facebook was that when adding it to the database, I don’t know why Facebook didn’t html entity it. So when Studio featched the contents, it became

And creating us a Beautiful, self executing XSS.

Nov 22, 2014 7:12am - Notified Facebook
Nov 24, 2014 1:30pm - Facebook Notified its out of scope
Dec 2, 2014 10:42am - Issue got fixed.
Dec 9, 2014 08:03am - Public Disclosure


No matter where the source is, do not trust user input data even while fetching it from a trusted source.

1 comment: