How the incorrect validation of the “Old Password Field” allowed me to reset the user’s password via CSRF!
This blog is about a security vulnerability, that I discovered back in 2021 on a website that was assigned to us for testing during our internship. I’m unable to use the real website name for security concerns, but for the sake of clarity, let’s use xyz.com. To understand this issue, we must first understand the CSRF vulnerability.
What is CSRF?
Cross-site request forgery (CSRF) is a web security flaw that allows an attacker to trick users into taking activities they did not plan to take.
A CSRF attack exploits a vulnerability in a Web application if it cannot differentiate between a request generated by an individual user and a request generated by a user without their consent.
In a successful CSRF attack, the attacker causes the victim user to carry out an action unintentionally. For example, this might be to change the email address on their account, to change their password, or to make a funds transfer.
Understanding Password Reset Mechanism
It’s a straightforward feature that requires you to enter your existing password in the “Old Password” area. The server or backend will then validate your password, and when it has been verified, it will allow you to modify the “New Password” and “Confirm New Password” fields to enter your new password. The below password box will not be enabled if the current password is incorrect. But while attempting to validate the current password, there is an issue.
The Issue or Vulnerability (Summary)
The vulnerability is that the server verifies the old password but not with the respective user. In order to better understand this, let’s use an example. There are two users, user1 and user2, and if you wish to change user1’s password and put user2’s current password in the “old password field,” as per security it should not be validated but in this situation it does, and you can change user1’s password without knowing user1’s current password. This is a weakness since the server checks the old password but not with the relevant user.
Vulnerability Description
To exploit the vulnerability, I initially established two accounts, User1, and User2. I then log in as a user1. I went to the change password page in user1’s account ( URL: https://xyz.com/change_password). The “old password” field is editable, but the “new password” and “confirm new password” fields are not; to make this field editable, we must input the correct old password. Turn on Burp Intercept and enter User1’s current password in the old password field. Intercept the request and send it to the repeater. When you click submit, you’ll notice that the answer says “true” since it checked the old password in its database.
Then, generate its CSRF-POC[1] and forward the request from the proxy tab.
After verifying the old password, the “new password” and “confirm new password” fields are now editable. Put a new password (as desired) in both fields. Intercept the request and make them build their CSRF-POC[2] as well.
Now we need to merge the two CSRF-POC and generate one CSRF-POC for exploit.
Open a new browser and log in as user2. Now open the combined HTML CSRF PoC file in user2’s logged-in browser.
Boom!
User2’s password has been changed to the password supplied in the HTML CSRF PoC file.
Because of incorrect validation in the “old password” field, which checks the password but not with the associated user account, I was able to reset user2’s password without knowing the current password of user2.
