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:
'">.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:
“Dropbox has teamed up with Facebook so that you can do cool things like add files from Dropbox to your Facebook groups or send shared folder invitations to your Facebook friends.”
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: '"> and shared it. Nothing awesome happened except the file being shared..txt
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:
'">
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 »