Find out how our Security Researcher Frans Rosén hacked Facebook and found a stored XSS for which he received a bug bounty reward.
I recently found a Stored XSS on Facebook, which resulted in a Bug Bounty Reward. If you want to know how an XSS could be exploited, you can read my colleague Mathias’ blog post about it. Anyway, here’s how it went down.
I was actually working on finding flaws on Dropbox to begin with. I noticed that when using their web interface there were some restrictions on what filenames that were allowed. If you tried to rename a file to for example:
'"><img src=x onerror=alert(document.domain)>.txt
it was not possible. You got this error:
But, if you instead, connected a local directory, created a file there and synced it, you got it inside Dropbox without any problems. Using this method I was able to find two issues with their notification messages showing unescaped filenames. I reported these issues to Dropbox, they patched it really fast and I was placed on their Special Thanks page for the responsible disclosure.
It didn’t end here. As I was testing out this stuff on Dropbox, I also tried to figure out how this issue could be connected with other services. I noticed their Facebook-connection and got curious on how it worked. It turned out that they had a pretty nice function going on there:
Nice! I created a group, and found the connection using the “Add File” icon on the Group wall:
I selected the file that I synced to Dropbox, it was called: '"><img src=x onerror=alert(document.domain)>.txt and shared it. Nothing awesome happened except the file being shared.
But then, I clicked the Share-link on the entry.
BAM! The title of the entry was not escaped correctly and I was able to get the Stored XSS triggered. By using the files in my Dropbox I could inject script code that was executed on Facebook.com.
I reported this to Facebook directly using their Whitehat Vulnerability Reporting system, told them it was an urgent issue and how I managed to get it executed. The issue was at that time only affecting the Share-popup inside the Group page and could only be triggered by user interaction, serious or not, it was clearly not affecting all users on Facebook.
At the same time I started looking on the URL of this Share-popup:
https://www.facebook.com/ajax/sharer/?s=44&appid=210019893730&p%5B0%5D=entry_id&p%5B1%5D=user_that_shared_it_first
This URL did not work if you tried it stand-alone. That was good, the XSS issue looked like it could only be triggered by user interaction. But then I started googling and found that you were able to create a Share-URL by using this format: https://www.facebook.com/sharer/sharer.php?
So I changed my URL to that format:
https://www.facebook.com/sharer/sharer.php?s=44&appid=210019893730&p%5B0%5D=entry_id&p%5B1%5D=user_that_shared_it_first
BAM again! If you were logged in into Facebook, the code was executed as soon as you visited the link. Bad. Really bad. I emailed Facebook again, explaining that you could actually trigger the XSS by only visiting a link.
I was also trying out if I could get other services to behave in the same way. Dropbox and Facebook had this special connection, so I was curious if this issue was isolated or if I could reproduce it by using another service.
Went to Pinterest. Created a Pin named:
'"><img src=x onerror=alert(document.domain)>
and shared it on Facebook using my test account. I pressed the Share button on it:
I was amazed – it had the same issue.
Facebook replied to me, asking me how I was able to place the files on Dropbox with that filename. I explained how this was done and also told them that the service that you shared from didn’t matter, it was a general issue with the escaping that created a vulnerable vector on the Share-page.
They responded and said that it was indeed the same issue and they should look into it ASAP.
In the meantime, I tried the link on different devices. My iPhone could not get the XSS executed. As soon as I visited the page, I was redirected to https://m.facebook.com and that page did not have the same issue. But I also realized that you could force Facebook to skip the redirect by using a parameter called m2w, so if I appended that to the URL:
https://www.facebook.com/sharer/sharer.php?s=44&appid=210019893730&p%5B0%5D=entry_id&p%5B1%5D=user_that_shared_it_first&m2w
I was able to trigger the URL on both mobile devices and on desktop. Another email to Facebook.
One day after that I noticed that the POC-link did not work anymore, it was finally patched. I told them I could not reproduce it anymore and it looked like it was fixed.
One day later I got this email:
Nice one!
Date range:
- Initial report and the POC-link executing the XSS just by visiting: Dec 22
- Explained the Dropbox-syncing and extended the scope regarding services and devices: Dec 27
- Vulnerability fixed: Dec 28
- Received message about the Bug Bounty: Dec 29
Frans Rosén, Security Advisor
Detectify is a fully automated web security scanner created by some of the world’s best ethical hackers. Give our free trial a whirl and check your website for vulnerabilities like Cross-site scripting »
