Wednesday, June 8, 2016 Anti-CSRF Token Bypass CSRF Vulnerability

I want to share my another finding on Mozilla which I have reported to them.

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
Cookie: JSESSIONID=SessionValue;; Secure; HttpOnly
Content-Type: application/x-www-form-urlencoded
Request-Type: XMLHttpRequest


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:

    <form action="" method="GET">
      <input type="submit" value="Submit form" />

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.


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.


All 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.


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.

Thursday, March 12, 2015

Logical Attacks(Vulnerability Research)

Hi Everyone.....please find my video presentation and ppt presentation on Logical Attacks(Vulnerability Research) which I have presented in Defcon & OWASP Lucknow International Information Security Conference. this presentation can be helpful in Bug Bounties while doing Bug Hunting, Vulnerability Research in web applications, mobiles(andriod, ios, win), webservices, apis etc and for making a career in information security domain.

Video Presentation:

Part 1: 

Part 2:

PPT Presentation:
Logical Attacks(Vulnerability Research):