5 Ways to test password reset function
Password reset is a function commonly founded in modern
web app. This function normally would be the first function I tested in every
web app as once a bug is founded, it is normally a critical one. In this
article, I would show several ways to test this function.
Before
going deep in how to test a password-reset function, first we need to know how
password-reset normally works.
When you need to reset
a password in a web app. A POST request like below
would be sent to the server.
Then, a link like below would be sent to victim@hackingtruth.org for reset password:
www.example.com/reset-password?token=abcd123kaj
The token would be used to identify which user is reseting their
password.
If the token is leaked to hacker, they would able to access the link and reset victim's password.
Another
common way to rest password is using OTP. Instead of sending a link with token
like above,
OTP (normally 6 digit) would be sent to user's
email and user needs to input correct OTP in order to reset
their password.
Ways to test password reset function -
#1 Test for password Reset link validation
- Try reset password with empty token (eg.
www.example.com/reset-password or www.example.com/reset-password?token=);
- Try using special character in token (eg.
www.example.com/reset-password?token=%00%00);
- Try decrypt
token using base65, MD5 decode or Timestamp etc);
- Check
pattern of the token. Are there any part of the token remain unchaged for
several requests?
- Can same password reset link be reused
and without expiration?
#2 Bypass OTP limit
Attacker can bruteforce the OTP of victim and reset their password.
There are several ways that you can try to bypass the OTP rate limit:
- Sometimes ratelimit only set for specific IP. Thus, you can try making POST
request from different IP to bypass rate limit.
- Sometimes
webapp password reset backend might be host in different server. Try sending
each request to different servers to bypass the rate limit.
- Try adding nullbytes after username or email (eg. %Z00, %0d%0a, %09, %0c,
%20, %0);
#3 Leakage of reset token/OTP
Sometimes, the webapp might leak reset token or OTP somewhere. Thus, you
can turn your burpsuite on all the time. Then, once you send a password reset
request, you can check if the reset token or OTP is leaked somewhere in the
traffic.
#4 Adding attacker's Email in POST request
Another method is try to add attacker's email in the POST request and
check if the password reset token or OTP would be send to attacker's email.
you can also try to send a POST request including both
attacker and victim's email:
#5 Host Header Injection
As you can see, we just replace the host header from
www.example.com to www.attacker.com.
victim would receive an email for reseting their password.
But instead of getting something like this:
www.example.com/reest-password?token=abcd123kajkkaj1kfk1
They would get something like below:
www.attacker.com/reset-password?token=abcd123kajkkaj1kfk1
Thus, if victim clicks on the link, attacker's hosted
server would receive request from victim. Attacker can either access the
password reset page using the token giving or host a phishing page to steal
victim's credential.
You can also try adding headers like
below to override the Host header at the backend:
X-Forwarded-For: www.attacker.com
X-Forwarded-Host:
www.attacker.com
Disclaimer
All tutorials are for informational and educational purposes only and have been made using our own routers, servers, websites and other vulnerable free resources. we do not contain any illegal activity. We believe that ethical hacking, information security and cyber security should be familiar subjects to anyone using digital information and computers. Hacking Truth is against misuse of the information and we strongly suggest against it. Please regard the word hacking as ethical hacking or penetration testing every time this word is used. We do not promote, encourage, support or excite any illegal activity or hacking.
