Anyways, getting to the vulnerability, the issue was that a user could delete his own address book with a single click URL, which is alright as long as the user wishes to do so himself. However, with the server not verifying whether the request was sent by the user himself or was the user was tricked into sending the request, the application allowed an attacker to generate a request on behalf of a logged in user from the user’s browser and perform the action (deletion of the address book).
The normal process would be as follows:
1. A user logs into mobile.twitter.com
2. If he wants to delete ALL his previously imported contacts, he would click on “Remove Contacts” under Settings.
3. Upon clicking, a GET request is sent to “https://mobile.twitter.com/settings/wipe_addressbook”
4. A message is presented that the the user’s contacts have been removed.
An attacker could take advantage of the absence of any security tokens (CSRF tokens) that would allow the server to authenticate the request and setup a page (and host it on xyz.com/index.html) similar to the following:
An attacker could then be made to navigate to xyz.com/index.html (via email or some other means) and his address book would be deleted!
The form that would make the final request has now been protected with a ‘authenticity_token’ which is random and changes on every login and without which the request is not processed on the server. An attacker would need to know this value to attack the application via CSRF.