| Field | Detail |
|---|---|
| Platform | PortSwigger Web Security Academy |
| Type | Business Logic — Inconsistent Access Control Validation |
| Difficulty | Apprentice |
| Objective | Access the admin panel and delete the user carlos |
Inconsistent Security Controls¶
Navigating to /admin:
Admin interface only available if logged in as a DontWannaCry user
The registration form noted:
If you work for DontWannaCry, please use your @dontwannacry.com email address
Admin access is tied to having a @dontwannacry.com email. The registration flow validates email ownership via a confirmation link — but the email update functionality lets you change the email post-registration without any verification at all. That inconsistency is the entire flaw: validation applied in one context but skipped in another. The attack required no technical bypass — just registering normally, then using a legitimate feature in an unintended sequence.
I registered with an external email via the exploit server:
POST /register HTTP/2
csrf=XOXH5Zap3Wr63sx3NjlXmBXbJeebuEPF&username=teto&email=attacker@exploit-0a9d001303199fa082e9f52801f1006d.exploit-server.net&password=teto
Clicked the confirmation link from the email client:
Account registered. On /my-account, I updated the email to [email protected]:
No confirmation link required. The account now held a @dontwannacry.com address, and privileged access based on email domain only works as a control if the system verifies ownership before granting access — allowing arbitrary post-registration email changes defeats the mechanism entirely.
Navigating to /admin:
Admin panel accessible. Clicking delete on carlos:
Lab solved 7.7