Twitter Wipe Addressbook CSRF Vulnerability
Bug writeup for a CSRF vulnerability in Twitter that allowed an attacker to trick a user into deleting the addressbook remotely.
I disclosed a CSRF vulnerability with Twitter, that could allow a malicious attacker to trick a user into deleting their address book of an unsuspecting user.
The issue was that a user could delete their own address book with a single click URL, which is alright as long as the user wishes to do this themselves. However, with the server not verifying whether the request was sent by the user themselves 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).
There was no CSRF protection available on the mobile version of Twitter where this flaw was found. Interestingly, this functionality is not available on the desktop version of Twitter.
The normal process would be as follows:
- A user logs into mobile.twitter.com
- If the user wants to delete ALL their previously imported contacts, they would click on “Remove Contacts” under Settings
- Upon clicking, a GET request is sent to “https://mobile.twitter.com/settings/wipe_addressbook"
- 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
example.com/index.html) similar to the following:
<html> <body> <img src="https://mobile.twitter.com/settings/wipe_addressbook" width="0" height="0" /> </body> </html>
An user could then be made to navigate to
example.com/index.html (via email or some other means) and their address book would be deleted, while they are logged into Twitter in the same browser!
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.