Hello Hackers,

Hope you guys Doing well and hunting lots of bugs and Dollars!

For today we are going to talk about some web security vulnerability, which occurs on password reset functionality. So for today, we will see a brief methodology and approach for finding bugs in this very common functionality.

Most of the web application provides users “ password reset “ functionality via email. This functionality has given which allow users to recover their account, generate a new password, and repair their own problems. so let’s start and learn how to look for bugs in this function.

Password reset link not expiring

when a user request changing password then he get a password reset link to reset the password, that’s the normal behaviour but it also should expire after some period of time. If it is not expiring and you can use the password reset link multiple times to reset the password. Then you can consider it as vulnerability.

No rate limiting on password reset

Rate limiting is used to control the amount of incoming and outgoing traffic to or from a network. Basically, no rate limit means there is no mechanism to protect against requests you made in a short frame of time. So try to send lots of requests, if it is not blocking you then you can consider it as vulnerability.

How to hunt:-

• Start the burp suite and intercept the password reset request
• Send to intruder
• Use null payload

Denial of service when entering a long password

Normally passwords have 8–12–24 or up to 48 digits. if there is no word limit while keeping a password you can consider it as vulnerability. you can check when you setting the password while changing passwords or creating accounts as a long string which can lead to DOS.

How to hunt:-

• Start the burp suite and intercept the password reset request
• Send to intruder
• Use null payload

Password reset token leak via referer

The HTTP referrer is an optional HTTP header field that identifies the address of the webpage which is linked to the resource being requested. The Referer request-header contains the address of the previous web page from which a link to the currently requested page was followed. So it is possible that the password reset token is leaking via referrer request-header.

How to hunt:-

• Request password reset to your email address
• Open on the password reset link
• Make sure you don’t change the password there
• On Password Reset Page Click On Social Media Links Given Below And Capture The Request Using Burp Suite
• Check if the referer header is a leaking password reset token?

User enumeration via Password reset page

The username enumeration is an activity in which an attacker tries to retrieve valid usernames from a web application. You can check this type of bugs on login pages, registration form pages or password reset pages.

How to hunt:-

• Go to the password reset page
• Enter a username that exists, there would be no error, and it will be redirected to the login page
• Enter a username that doesn’t exist, there would be an error saying something like ‘user account doesn’t exist’ etc.

Password reset with manipulating email parameter

while requesting a password reset link for the victim user, we can try the below parameter manipulation to get a copy of the reset link of the victim on the attacker email.

• Double parameter (aka. HPP / HTTP parameter pollution):
  [email protected]&[email protected]
• Carbon copy:
  [email protected]%0a%0dcc:[email protected]
• Using separators:
  [email protected],[email protected]
  [email protected]%[email protected]
  [email protected]|[email protected]
• No domain:
  email=victim
• No TLD (Top Level Domain):
  email=victim@xyz
• JSON table:
  {“email”:[“[email protected]”,”[email protected]”]}

weak cryptography issue

Generally resetting passwords using a URL is a well-known practice that is implemented in lots of web applications. But less secure implementation of this method uses a URL with an easily guessable parameter to identify which account is being reset.

http://example.com/reset-password?user=victim-user

As here user parameters can be changed to any other username and change their password without proper authorization which can lead to account takeover.

so web-application generate a token that is hard to guess which will indicate a username on a password reset URL like
http://example.com/reset-password?token=a2nb20248130okbbw2a0

There should be no hint about which user’s password is being reset in the URL. but then also if we decode it due to a weak cryptography issue then you can consider it as vulnerability.

The basic idea is just to find out how password reset token is generated:-

• Generated based timestamp
• Generated based on cryptography
• Generated based on userID
• Generated based on email user
• Generated based on first name and last name
• Generated based on the date of birth

Password reset Poisoining leads to token leak

Password reset poisoning is a technique whereby an attacker manipulates a vulnerable website into generating a password reset link pointing to a domain under their control. This behaviour can be leveraged to steal the secret tokens required to reset arbitrary users’ passwords and, ultimately, compromise their accounts.

How to hunt:-

• Intercept the password reset request in Burpsuite
• Add following header or edit header in burp suite(try one by one)

You can use ngrok server as your attacker server

Host: attacker.comHost: target.com
 X-Forwarded-Host: attacker.comHost: target.com
 Host: attacker.com

Then forward the request and see if you get the link given below then you can consider it as a vulnerability.

https://ngrok.server/reset-password.php?token=12345678-1234-1234-1234-12345678901

Hope this is useful for you guys

Happy Hacking!