On this page
apsyleg1 min read
#portswigger #deserialization #web-security

Modifying Serialized Data Types

Lab

Modifying serialized data types · Apprentice

Solution

Given

This lab uses a serialization-based session mechanism and is vulnerable to authentication bypass as a result. To solve the lab, edit the serialized object in the session cookie to access the administrator account. Then, delete the user carlos.

You can log in to your own account using the following credentials: wiener:peter

Analyzing the task

Everything is like the previous lab. The deserialized object in the cookie looks like this:

O:4:"User":2:{s:8:"username";s:6:"wiener";s:12:"access_token";s:32:"j3yljb7ebbyibjkzd0aeqgmdlcbsh1qk";}

Exploitation

To bypass the access_token check, we abuse a flaw in the string comparison implementation that uses ==. If we pass 0, the comparison 0 == "string" returns true.

So we need to change the access_token type to numeric. The final payload:

O:4:"User":2:{s:8:"username";s:6:"wiener";s:12:"access_token";i:0;}

Replace the cookie — the admin panel shows up. Delete the user carlos. Lab solved!

More in this category

Using Application Functionality to Exploit Insecure Deserialization (PortSwigger Lab)

Tampering with the `avatar_link` field in the session object to delete an arbitrary file via the account-delete feature.

Modifying Serialized Objects (PortSwigger Lab)

Flipping the `admin` boolean inside a PHP-serialized session cookie to gain administrative privileges.

Web Shell Upload via Extension Blacklist Bypass (PortSwigger Lab)

.php is blacklisted, but .htaccess uploads without complaint — we slip our own Apache config in and make the server execute shell.bug as PHP.