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

This is a cool Second-Order-Injection XSS against Facebook Studio that was caused by data input on Facebook Mobile (Facebook Studio).

This vulnerability is created 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. which means, there needs to be no linkshim because it was first checked on Facebook.

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, it obviously didn't work.

Then I tried URL encoding. There is a value in html called shy. That basically, shies/hides 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 

http://something.com”onmouseover=”alert(1);//&shy;.

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. 

http://something.com”onmouseover=’alert(31337);’style=”font-size:100; background:black”&shy;.

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

<a href=”http://something.com”onmouseover=’alert(31337);’style=”font-size:100;background:black”&shy;.”” target=’_’ >X</a>

And creating us a nice self executing XSS.

www.vulnerability-lab.com/get_content.php?id=1368

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