I originally wasn’t going to publish this, but @phwd wanted to hear about some of my recent bugs so this post is dedicated to him.
When Messenger.com launched back in April, I quickly had a look for any low-hanging fruit.
One of the first things to do is check end-points for Cross-Site Request Forgery issues. This is whereby an attacker can abuse the fact that cookies are implicity sent with a request (regardless of where the request is made from), and perform actions on another users behalf, such as sending a message or updating a status.
There are different ways of mitigating this (with varying results), but usually this is achieved by sending a non-guessable token with each request, and comparing it to a value stored server-side/decrypting it and verifying the contents.
The way I normally check for these is as follows:
- Perform the request without modifying the parameters, so we can see what the expected result is
- Remove the CSRF token completely (in this case, the
- Modify one of the characters in the token (but keep the length the same)
- Remove the value of the token (but leave the parameter in place)
- Convert to a GET request
If any of the above steps produce the same result as #1 then we know that the end-point is likely to be vulnerable (there are some instances where you might get a successful response, but in fact no data has been modified and therefore the token hasn’t been checked).
Normally, on Faceboook, the response is one of two, depending on if the request is an AJAX request or not (indicated by the
Either a redirect to
Or an error message:
I submitted the following request to change the
sound_enabled setting, without
Which surprisingly gave me the following response:
I tried another end-point, this time to remove a user from a group thread.
Which also worked:
After trying one more I realised that the check was missing on every request.
Simple and quick fix - tokens are now properly checked on every request.