| Field | Detail |
|---|---|
| Platform | PortSwigger Web Security Academy |
| Type | Business Logic — Privilege Assumption via User-Controlled Input |
| Difficulty | Practitioner |
| Objective | Access the administrator account and delete the user carlos |
Weak Isolation on Dual-Use Endpoint¶
I logged in as wiener:peter.
The account page has a password change form. Intercepting it:
POST /my-account/change-password HTTP/2
csrf=daK74c2jYeR1QULBeSHLzj9BEZRSbG3c&username=wiener¤t-password=peter&new-password-1=teto&new-password-2=teto
username is a client-supplied parameter in the body. The endpoint appears to handle both a regular password change (current password required) and some admin-style reset (no current password required), sharing the same route and trusting the client-supplied username to determine whose password gets changed. Removing a parameter rather than providing a wrong value is worth trying whenever a field is used for security — "field missing" and "field wrong" can hit different code paths, and one of them might not enforce the check at all.
Removing current-password and changing username to administrator:
POST /my-account/change-password HTTP/2
csrf=daK74c2jYeR1QULBeSHLzj9BEZRSbG3c&username=administrator&new-password-1=teto&new-password-2=teto
Request succeeded. The server skipped the current-password check when the parameter was absent entirely, and accepted administrator as the target username without verifying the requester owned that account. Logging in as administrator:teto:
Going to /admin and clicking delete on carlos:
Lab solved