I disclosed a CSRF vulnerability with Twitter, that could allow a malicious attacker to wipe the address book of an unsuspecting user. I reported the vulnerability in the beginning of March and they fixed it on the 22nd! I wouldn't want to comment on the process and internal business logic that they follow, but honestly that was a a pretty long period for them to come up with a fix.
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 his address book, he would click on Delete Address Book 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:
<img src="https://mobile.twitter.com/settings/wipe_addressbook" width="0" height="0" />
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.
This was my ticket to the Twitter Hall of Fame for Security researchers at Twitter / Security!