| Field | Detail |
|---|---|
| Platform | PortSwigger Web Security Academy |
| Type | Business Logic — Email Truncation to Bypass Domain Check |
| Difficulty | Practitioner |
| Objective | Access the admin panel and delete the user carlos |
Inconsistent Handling of Exceptional Input¶
Navigating to /admin returned the familiar message:
Admin interface only available if logged in as a DontWannaCry user
I registered normally with a real exploit server email and received the confirmation link — account created, but unlike the previous inconsistent-controls lab, there's no email update functionality post-registration. That meant I needed to manipulate the email at registration time itself.
I tested with an inflated local part — a very long string before the @:
The stored email had the @exploit-server.net suffix stripped — the server truncates to 255 characters. The @ and everything after it were cut off. That's the vulnerability: length limits applied inconsistently across the flow. The confirmation email is sent to the full pre-truncation address, but the stored value is only the first 255 characters. Both checks need to operate on the same representation of the email — they don't.
By sizing the A prefix so that @dontwannacry.com ends at exactly character 255, the exploit server domain becomes a subdomain appended after that point — which gets truncated on storage but still routes the confirmation email to our inbox:
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAA@dontwannacry.com.exploit-0afd006704a2399c803d57a801ea002c.exploit-server.net
The A string is sized so @dontwannacry.com ends at character 255. Everything after — .exploit-server.net — gets truncated on storage.
Registering the account:
Confirmation email arrived at the exploit server:
Clicking the link and logging in:
The stored email ended in @dontwannacry.com — the domain check at login operates against the stored (truncated) value, not the original full address. Navigating to /admin:
Admin panel accessible. Clicking delete on carlos.
And that gets the lab solved :P