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.
Test Scenarios:
- 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
- Try setting these request headers during password reset and check the response.
X-Forwarded-For:
X-Forwarded-Host:
X-Forwarded-Proto:
X-Host:
X-Forwarded-Server:
X-HTTP-Host-Override:
Forwarded:
X-Server:
X-Custom-IP-Authorization:127.0.0.1/localhost
- Check for IDOR via email address/username/userid in http request
- Check for request smuggling using smuggler tool
- Parameter Pollution:
- check for email=victim@mail.com,hacker@mail.com
- check for email=victim@mail.com;hacker@mail.com
- 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=victim@mail.com&email=hacker@mail.com
- 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!!!
If you like the content, please follow me on medium and LinkedIn
LinkedIn: https://www.linkedin.com/in/pravin-r-p-oscp-28497712b/
