17 April 2013
Category: Hacks, Uncategorized
17 April 2013,

A Few of My Favorite Facebook Stored XSS Findings

Today, I’m going to share a few of my favorite Stored XSS Findings in Facebook (Facebook Chat, Facebook Check In, Facebook Messenger. These findings are almost always interesting if you happen to find them in the right location.

For instance, what would occur if the Malicious Stored XSS Payload ran on the victim every time they checked in? You could also inject the Payload into the Facebook Chat Screen, which could be really interesting.

There are essentially two different ways to exploit Stored XSS issues.


Let the victim visit our stored XSS Payload (Facebook Check-In, Facebook Messenger, Facebook Chat) on their own.


Exploit it with the URL plus the Stored XSS data.

I wanted to locate an interesting spot within Facebook that would run the data on the victim each time they visited one of my places. I could also just run it through Facebook Chat.

This post will talk a lot about Stored XSS in regard to Facebook Chat, Check-In, Facebook Messenger (Windows Version).

The vulnerabilities mentioned here has been confirmed patched by the Facebook Security Team

Bug 1,

Stored XSS In Facebook Chat

When a user starts a new message within Facebook that has a link inside, a preview GUI shows up for that post. The GUI is used for presenting the link post. For this action, Facebook added extra parameters for the “post message” request.

I found an interesting parameter that looked like this:


I noticed that Facebook does not verify whether or not the attachment[params][urlinfo[final] parameter is a legitimate link (http, https). So, it’s relatively easy for an attacker to alter those parameters to make them a malicious request.

For instance:

attachment[params][title]=PoC Click Me&attachment[params][urlInfo][final]=javascript:alert(6)

Facebook will later take those parameters and insert them into a “href” tag.

<a href=”javascript:alert(6)”>PoC Click Me</a>

Each time the victim clicks on this malicious message in Facebook Chat, the Stored XSS will begin to run on their client.

PoC Video:


Bug 2

Stored XSS In Facebook Check In

The other major Stored XSS that I located is in the Facebook Check-In Screen. This is a cool one because the XSS runs every time they visit the places that the attacker has been.

To make use of the Stored XSS in Facebook Check-In, the attackers needs to first construct a new location within Facebook Pages (https://www.facebook.com/pages/create/).

Then, the attacker must change the settings in this new location. For instance, they can alter the address info on the place settings to something like:

<img src=”a.jpg”onerror=javascript:alert(6)>

When the victim later decides to go to the place the attacker has been, a Stored XSS will run client-side.

Bug 3

Stored XSS In Facebook Messenger (Windows)

I also noticed that an attacker is capable of injecting a Stored XSS Payload in Facebook Messenger for Windows. Any time the victim logs into their account in the Messenger, The Stored XSS will be run on his account.

But, let’s stay focused on the issue at hand. In Facebook Messenger, I noticed that Facebook does not filter the page name. Facebook won’t permit  you to make a name on Facebook with a Malicious Payload.

For instance:

Page Name:<xxxx>

For this to work, we need a user with a malicious name to be able to send a message to the victim.,

For example:

page name:<img src=”a.jpg”onerror=javascript:alert(6)>

So, how do we do this?

Facebook has an option to create a new page, correct?


In addition, pages are allowed to send messages directly to the users in Facebook.

So, if we change the name of our page to a JavaScript payload,


and then send a message to the victim from that page,

what would happen?

In this case, every time the victim logs into Facebook Messenger, a Stored XSS Payload would be run on their account.

PoC Video:


By @Nirgoldshlager


15 responses on “Stored XSS In Facebook Chat, Check In, Facebook Messenger

  1. Tobias Timpe says:

    Wow, great work dude.

  2. […] Tweet Nir goldshlager from Break Security uncovers some stored XSS on Facebook Stored XSS In Facebook Chat, Check In, Facebook Messenger | Break Security […]

  3. Piyush Malik says:

    Simply Best !! 🙂

  4. longcat says:

    You basically keep fuzzing everything???

  5. Priyanshu says:

    Awesome work bro… 🙂
    Facebook would think about to hire you as Facebook security researcher.. 😛

  6. Daud Zaidi says:

    Nice work dude 🙂

  7. 你好強 says:

    great works!
    can you share more “how to” techniques?

  8. […] (XSS) geschlossen, die von der Sicherheitsfirma Break Security gefunden wurden und nun genauer beschrieben werden. Wie Firmenchef Nir Goldshlager darlegt, ließ sich das soziale Netzwerk unter anderem über […]

  9. […] scripting (XSS) holes that were discovered by security firm Break Security and which have now been described in greater detail. Break Security’s CEO, Nir Goldshlager, explains that the social network […]

  10. […] (XSS) holes that were detected by confidence organisation Break Security and that have now been described in larger detail. Break Security’s CEO, Nir Goldshlager, explains that a amicable network was […]

  11. Mohaab says:

    Great findings as always 🙂

  12. Asaf Cohen says:

    Facebook should hire you directly 🙂 Good Job

Leave a Reply

Your email address will not be published. Required fields are marked *