This is going to be a series of blogs in web application security test scenarios and this is one of them. As we all know, web applications have become an integral part of our life. People use web applications for most of the services. Customers register and store their personal data in some company’s web applications. There are so many attacks targeted on web applications by attackers. At the same time, organizations ask penetration testers to identify the loop holes/ vulnerabilities existing in web applications before the attackers do.
As part of the security assessment, the penetration tester will perform different test scenarios to identify the vulnerabilities. Today, I would like to list down what all test scenarios can be tested related to password reset functionality. I presume penetration testers know what is meant by password reset. If not, I kindly request you to google it and get little hold of the concept.
Below is the mind map created for password reset test scenario.
- Try to crack the password reset token if it is weak or it follows any patterns based upon the user
- Is it possible to change any parameter pertaining to a user in http response(response header/body values)so that it can impact to the password reset function. Sometimes, amending some critical values in http response might lead you to authentication bypass
- Token leakage via referrer header: Password reset token is leaked via referrer token or not.
- Check if host header is changed to attacker.com and whether or not token is leaking to the attacker
P2-Token Leakage Via Host Header Poisoning (Weak password Reset Implementation)
Vulnerability Category: A3- Sensitive Data Exposure
- Try setting these request headers during password reset and check the response.
concrete5 disclosed on HackerOne: Password Reset link hijacking via...
Summary Concrete5 uses the `Host` header when sending out password reset links. This allows an attacker to insert a…
New Relic disclosed on HackerOne: Host Header Injection
Reproduction 1- open reset link https://login.newrelic.com/passwords/forgot 2- Enter the victim's email address and…
- Check for IDOR via email address/username/userid in http request
Request password reset to your email address Click on the password reset link Don't change password Click any 3rd party…
- Check for request smuggling using smuggler tool
Slack disclosed on HackerOne: Mass account takeovers using HTTP...
This researcher exploited an HTTP Request Smuggling bug on a Slack asset to perform a CL.TE-based hijack onto…
Zomato disclosed on HackerOne: Stealing Zomato X-Access-Token: in...
Account takeover vulnerability using HTTP Request Smuggling and Desync attacks, this time through Akamai en route to…
- Parameter Pollution:
- check for email@example.com,firstname.lastname@example.org
- check for email@example.com;firstname.lastname@example.org
- Check for email=offsecdawnbughunter2%40gmail.com%0d%0acc:offsecdawnvictim1%40gmail.com
- Change http method(GET/POST) and try
- Change the content type of the request and try parameter pollution
- check for email@example.comfirstname.lastname@example.org
- Check for emailid=victim%40gmail.com~~attacker%40gmail.com
I have complied these scenarios based on my assessment. However, I did not give the screenshots for each scenarios since it will be a huge blog to go through.
I hope it is useful in terms of reference for penetration testing and I know there are multiple resources our there in internet. You can add this reference also along with other reference. Hope this makes little difference at least!!!