AppSec Tales V | Pass Change - Pentestmag

AppSec Tales V | Pass Change

AppSec Tales V | Pass Change

by Karol Mazurek


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.
Source: Own study —Example of password change form & process chart.

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.

 

Source: Own study — Testing Insecure Direct Object Reference on password change (fuzzing wordlist).

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.
Source: Own study — Examples of password guessing and spraying attack.

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.
Source: Own study — Preparing 1 000 invalid password wordlist for testing.

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.
Source: Own study — Password policy guidelines (10,000 common password wordlist).

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.
Source: Own study — Example of missing password field masking.

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.
Source: Own study — Example of sensitive data transmitted in the path and using HTTP.

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 ;]

 

August 29, 2022
Subscribe
Notify of
guest

This site uses Akismet to reduce spam. Learn how your comment data is processed.

0 Comments
Inline Feedbacks
View all comments

© HAKIN9 MEDIA SP. Z O.O. SP. K. 2013

"PowerShell for Pentesters"
Join our newsletter and receive one of our premium issues for free.
x