XSS Bug on Facebook Studio

8:41 AM



VL-MAG: http://magazine.vulnerability-db.com/?q=articles/2014/12/11/whitehat-hacker-discovered-details-application-side-facebook-studio-dashboard

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 facebook-studio.com 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: Evilzone.org is a site blocked by Linkshim.

Meaning, if I add “google.com” 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 evilzone.org is blocked, to bypass it with EVILZONE.org 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;zone.org” >X</a> is equvallent to evilzone.org so all I had to do is add evil&shy;zone.org 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;zone.org” >X</a>” when clicked redirects to evilzone.org, 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 http://something.com”><script>alert(0);</script> but that link become

<a href=” http://something.com”” 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=” http://something.com”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

Conclusion

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

You Might Also Like

1 comments