Application Security Testing of the Password Change form guidelines.
INTRODUCTION
This is the fifth article in the AppSec series which describes how to test Password Change forms to ensure a secure authentication process.
The advice in this article is based on:
- OWASP Web Security Testing Guide
- OWASP Application Security Verification Standard
- NIST recommendations
- bug bounty reports
- own experience.
I will provide a short test sample, a potential impact or an attack scenario, and a possible solution to the problem at each point.
GUIDELINES
I. UNVERIFIED PASSWORD CHANGE
Check if the password change process flow is implemented correctly.
- If the attacker successfully exploits another flaw, like CSRF or XSS in the application, he could change the victim’s password.
- With temporary access to the victim’s account (e.g. physical access to a device with an active session), an attacker could associate a new password to the account.
Password verification on pass change requests should be implemented.
II. IDOR
Abuse the Pass Change API by issuing another account email.
- An attacker could hijack the victim’s account just by knowing its email.
The API should reject the password changes of another user without verification.
Password verification on pass change requests should be properly implemented.
III. BROKEN LOGIC
Send multiple values using parameter pollution or an array variable.
- With temporary access to the victim’s account, an attacker could guess a user password using a few requests.
API should not accept multiple values for the parameters during authorization.
IV. RATE-LIMITING
Try to change the password 1000 times in seconds.
- With temporary access to the victim’s account, an attacker could brute-force the old password.
- Could lead to Denial of a Service.
Restrict the consecutive requests through mechanisms like time delay, CAPTCHA, or other controls. No more than 100 failed attempts per hour should be possible on a single account.
V. BROKEN SESSION INVALIDATION
Change the password and check if other active sessions have expired.
The application should prompt for session termination on password change or log out the user from all active sessions, except the current one.
VI. PASSWORD POLICY
Check if the password policy complies with current standards.
- The password could be brute-forced easier.
- If the database was leaked, the passwords could be cracked more easily.
Password policy is volatile, always refer to the latest Application Security Verification Standard recommendations.
VII. MISSING PASSWORD FIELD MASKING
Check if the software does mask passwords during entry.
- Increasing the potential for attackers to observe and capture passwords.
Include a password field mask and an option to view the masked password.
VIII. CREDENTIALS OVER AN UNENCRYPTED CHANNEL
Check if data is transferred via HTTP or as a parameter in the URL.
- Sensitive data may be logged by the browser, the webserver, and forward or reverse proxy servers between the two endpoints.
- It could be also displayed on-screen, bookmarked, or emailed around by users.
- They may be disclosed to third parties via the Referer header when any off-site links are followed.
Sensitive data in the URL and sent using not secure Hypertext Transfer Protocol increases the risk that it will be captured.
IX. INPUT VALIDATION
Check the AppSec Tales I and AppSec Tales II.
Check the Input Validation Cheat Sheet from OWASP.
FINAL WORDS
Testing any element of a Web Application is like sailing the open ocean.
Treat the WSTG like the compass and the ASVS like azimuth.
However, do not forget that someone had to invent it. Therefore you always have to look for new ways that you will not find in the WSTG or here, but you have to find them yourself.
Nevertheless, I hope you will find this article useful and keep coming back to it. I also encourage you to comment if you have an idea for a point for this article or if you find any bugs here ;]
