The Facebook badges page was vulnerable to stored Cross-Site Scripting (XSS). This was initially reported back in August 2013, but due to communication problems over e-mail it wasn’t fixed until early January. Neither party is to blame, but this shows some of the difficulties that companies can face communicating with security researchers.
This problem hit the media earlier this year when a Facebook security report was not clearly understood and led to the exploit being abused on Mark Zuckerberg’s wall.
Facebook recently moved their Whitehat communication to their support dashboard instead of over e-mail which is going to help the company and security testers tremendously.
When this request is sent, it would return the following source:
Source: <div class=”badge_holder bh_horiz“>
The layout request variable was being saved to a database and pulled into the <div>’s class. Because the input was not encoded, it allowed you to break out of the div and inject HTML.
Normally I would show an iframe or script alert as an example, but this is the only screenshot I still have of this. The entire badge page has since been completely overhauled and no longer functions in a way that a string is passed by the client to a database to be saved.
That means no one can force you to make this request, you would have to damage yourself or the attacker would have to already have access to your Facebook. Even still, you would have to visit the badge page in order for it to execute.
I’m going to bet a lot of you haven’t even heard of the badge page until you read this.
Regardless, XSS is XSS! It can force you to execute any action protected by a csrftoken and extract information from your Facebook. That means forcing you to make Facebook posts or stealing private data that you didn’t want public.
Submitted: August 2013
Fixed: January 2014