While researching and working on bug bounties I have found that by using Reflected HTTP Parameter Pollution vulnerability we can bypass Anti-CSRF token validation and can execute CSRF and after that using the CSRF we can execute the Stored HPP vulnerabilty and can compromise any victims account if that site is vulnerable to these attacks.

The 1st challenge was to execute the CSRF attack by bypassing the Anti-CSRF token validation. I have found that using Reflected HTTP Parameter Pollution vulnerability we can bypass the CSRF token validation even when the token is properly getting validated on server-side.

The actual rootcause of this vulnerability existence is that if the Anti-CSRF token parameter is used 2 times in a request then the 2nd Anti-CSRF token parameter value(the value will be attacker desired) is getting accepted and validated on the server-side instead of the 1st Anti-CSRF token. One more important point is that the if we try to use any random CSRF token value using single CSRF token parameter then it was getting denied by the server and the request is getting blocked as the Anti-CSRF token was properly getting validated on the server-side.

The 2nd Challenge was to execute the Stored HTTP Parameter attack by finding the email parameter name and editing it with attackers email id. I have found that using CSRF vulnerability we can execute the Stored HPP vulnerability so using it we can edit the victims account email id to attackers email id but for that the attacker has to find the email id parameter name, so to find it the attacker can guess that parameter name, can fuzz it and can find the parameter name by using the forget password, reset password or login page Urls.

The actual rootcause of this vulnerability existence is that if the email id parameter is added with the attackers email id in the request using the CSRF vulnerability then the uneditable email id of victims account is getting edited or changed with the attackers email id.

In this way the attacker can easily change the victims account login email id and he has to confirm the changed email id by logggin into his email id and by clicking on the email confirmation link. Once the attackers email id is confirmed into the victims account, then the attacker can use the forget password option to reset the victims account password and after that attacker can change the victims account password and can compromie his account.

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:

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

Anti-CSRF token validation can be bypassed and uneditable account login email is can be changed. This can lead to account compromise.

Recommendation:

CSRF token shall be properly validated on server-side and put method can also be used instead of post.

Filtering of all incoming sharing requests that include duplicate parameters.

So in this way, using this multiple vulnerabilties chaining one can bypass Anti-CSRF token validation and can also compromise the victims account also these techniques can be used to find same type of vulnerabilities on different websites.

Thank you so much Ajay for your efforts in writing and sharing it with us . I have a query .
How do you call it as "Bypass" since you are actually sending Valid Token along with an invalid Token .
As per your post , On sending an invalid token server actually denies the request . when you were actually able to add a single invalid CSRF token request and the server doesn't validate then , you can call it as bypass . Right ? Am i missing something here ? can you please make me understand how