| Field | Detail |
|---|---|
| Platform | PortSwigger Web Security Academy |
| Type | Insecure Deserialization — Application Functionality Abuse via Serialized Object |
| Difficulty | Practitioner |
| Objective | Edit the serialized object in the session cookie to delete morale.txt from Carlos's home directory |
| Note | Credentials wiener:peter and backup account gregg:rosebud |
Using Application Functionality to Exploit Insecure Deserialization¶
I logged in as gregg:rosebud and decoded the session cookie from /my-account:
O:4:"User":3:{s:8:"username";s:5:"gregg";s:12:"access_token";s:32:"stq4f3pktazihdk7ethi8gw9jdm2mcbv";s:11:"avatar_link";s:18:"users/gregg/avatar";}
Three properties: username, access_token, and avatar_link — currently pointing at users/gregg/avatar. The account page has a "delete account" button. When an account is deleted, the server presumably cleans up whatever avatar_link points to. If that cleanup doesn't validate the path, pointing avatar_link at an arbitrary file path and triggering the deletion would delete that file instead. The vulnerability isn't in the deserialization itself — it's in what the application does with the deserialized value: a dangerous method invocation against an attacker-controlled path.
Modifying avatar_link to point at /home/carlos/morale.txt and updating the string length accordingly (s:23):
O:4:"User":3:{s:8:"username";s:5:"gregg";s:12:"access_token";s:32:"stq4f3pktazihdk7ethi8gw9jdm2mcbv";s:11:"avatar_link";s:23:"/home/carlos/morale.txt";}
The serialized string length must match the actual value exactly, or deserialization fails — adjusting s:18 to s:23 is a required step when modifying string values.
The first attempt deleted the account without applying the modified cookie in the browser first, which consumed the gregg account. I switched to wiener:peter and applied the modified cookie into the browser's storage instead:
Clicking "delete account":
The server's cleanup logic ran against /home/carlos/morale.txt the file was deleted.
Lab solved :P