CSRFing Facebook games

One Sunday upon waking and making my morning coffee, I decided I wanted to help the world of Facebook gaming to be a better place. The first thing to remember is Facebook deem apps.facebook.com to be out of scope for their own disclosure program. This is due to the applications generally being webpages with a facebook header overlay, therefore not made by Facebook. Any disclosures would go to the developers of the game.

To start I decided I would go to the apps/games section of Facebook and randomly open 10 different games. I then went through these games and tried to find any potential vulnerabilities that exist. After about an hour I had 3 CSRFs and one of which you could perform a POST to GET conversion to make the exploiting a bit easier.

What happened to the other 7 you ask? Well, other factors that were totally out of my control (Hangover from Saturday night) got in the way… unfortunately. In the end I do believe I was lucky to get the 3 below.

Mob Wars CSRF to Reflected XSS with POST to GET conversion

Mob Wars is a game I have been playing for a while now and have found XSS in before. This time I have found it again in the Mob Code system. This system allows users of the game to add other user IDs to become friends. Mob Codes come in the form of “9c0a55”. But why put input a normal user ID when you can input something arbitrary, right?

Oh, look – we have Cross Site Scripting via the POST request to the Mob Code system. The code which was used to POST can be seen below:

Although why send a POST request when they allow POST to GET conversion? This way you can just send a link to your target rather than having to code up some JavaScript to get the POST to send.

GET Request Link:

You can go ahead and change the script to do whatever you like although getting session cookies is a good start. You could also use a URL shortening service such as www.bitly.com to make the not so attractive URL above into something pleasing and less dodgy, see below:

Pretty GET Request Link:

METROPOLIS Account deletion CSRF

The next game is METROPOLIS. This is a nice CSRF which when a POST request is made, will delete the user’s account. Which I imagine would be very annoying if you have been playing the game for a year and your account gets deleted. Although even more annoying if you delete the account while testing its functionality for security, I imagine…

The HTML below shows the POST request which deletes a user’s account when sent. This one did not have a POST to GET conversion although coding some JavaScript to send a POST request when a webpage is loaded is trivial. Here’s one I made earlier:

The horror if this was put into the METROPOLIS forums.

Anonymous Game account takeover CSRF

Now here is my favourite of them all. Stealing Mob Wars session cookies to impersonate a user is interesting. Deleting user accounts is pretty soul destroying if you have spent a long time building it up. But here we have an account takeover via CSRF in a game I will not name.
The reason I will not name this game is because I tried to contact the developers for 3 weeks about this issue to no avail. I later tracked down the exact person who developed the game and found a few 10 month old unanswered comments about development of the game and if it was continuing.

It does seem this game has stopped its development but also seems many people still play the game. It would not be right to disclose the developer or the game in which the vulnerability was found, so I won’t, but here are the vulnerability details.

The HTML below sends a POST request to the User Credentials page on the game which allows the user to change their details. Although of course the email and password being POSTed would be my own, not theirs. Once the details have changed I can now access the player’s account and interestingly also the Games forum as the change is made there too. Double winning.

But hey! At least the developers filter XSS attacks.
As you can see in the screenshot above, my username is “alert[1]”

Final Thoughts and Methodology

When it came to my methodology for searching for CSRFs, it was very simple. I looked for functions in game that would annoy a user or allow me to leverage an account for my own benefit. If I found something, for example an account deletion function, I looked in the HTML for any sign of an authentication token.

If I found no token, I would take the POST parameters and create a Proof of Concept HTML to see if the POST request would do what I wanted. In the case of the three above, they all worked and the CSRF was successful.

There is not much to say when recommending a CSRF fix: developers just need to make sure application pages contain unpredictable validation tokens so the application knows it is the user calling the function, rather than the user unwittingly calling the function because a web page has spoofed it for them.

It is also important to distinguish between POST and GET. The former should be reserved for functions that change the state of the application, and should require the unpredictable anti-CSRF token to be present – if it’s not there or it’s wrong, the session should be terminated. GET should be for functions which do not change state, such as reading data. Many frameworks also provide for automatic CSRF prevention these days, but generally only for POST (or PUT/DELETE) requests.

In addition, password change functions should always ask for the old password to prevent account hijacking.

All CSRFs were disclosed on 20/08/2016

• Metropolis Fixed 22/08/2016 – Thanked for the find
• Mob Wars Fixed on 23/08/2016 – Awarded in-game currency with a cash value
• Anonymous game. Not fixed.