> For the complete documentation index, see [llms.txt](https://ganesha-hk.gitbook.io/cybersecurity-writeups/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://ganesha-hk.gitbook.io/cybersecurity-writeups/port-swigger-insecure-desiralization-labs/lab-2.md).

# lab-2

## Modifying Serialized Data Types

**Difficulty:** Practitioner

### Lab Description

This lab uses a serialization-based session mechanism and is vulnerable to authentication bypass due to a PHP type comparison quirk.

**Objective:** Edit the serialized object in the session cookie to access the administrator account, then delete the user `carlos`.

**Credentials:** `wiener:peter`

> **Note:** PHP's comparison behaviour differs between versions. This lab assumes behaviour consistent with PHP 7.x and earlier.

### Root Cause

Developers often fail to keep their frameworks updated. In PHP versions prior to 7.x, the loose comparison operator (`==`) compares values without checking data types. This means `0 == "abc"` is treated as `true`, because PHP converts the string to the integer `0` before comparing.

If an attacker changes a data type in the serialized object from string (`s`) to integer (`i`) and sets the value to `0`, the backend comparison may be bypassed entirely. For example, if the serialized cookie contains:

```
s:12:"access_token";s:9:"abcdefghi"
```

The backend likely validates it as:

```php
if ($user['access_token'] == $real_access_token)
```

If the attacker changes the type to integer and the value to `0`:

```
s:12:"access_token";i:0
```

The server evaluates `0 == "abcdefghi"`, which PHP converts to `0 == 0` — always `true` — and the validation step is bypassed.

### Exploitation

1. Start the login flow and capture the request in Burp.
2. Find `GET /my-account?id=wiener` and send it to Repeater.
3. Decode the cookie: URL-decode → Base64-decode → inspect the PHP serialized object.
4. Replace the `username` value and the `access_token` value as follows:

   ```
   s:8:"username";s:13:"administrator";s:12:"access_token";i:0;
   ```
5. Re-encode the modified object: Base64-encode → URL-encode, then replace the cookie.
6. Update the URL to `GET /admin` and send the request — a `200` response confirms access.
7. Open the response in the browser, delete `carlos`, and complete the lab.

### Lesson Learned

* Never deserialize user-controlled data without verifying its integrity. An attacker can modify not only object values but also their data types.
* Serialization preserves data types. During deserialization, an integer remains an integer and a boolean remains a boolean — this allows attackers to supply unexpected types that would never arrive through standard HTTP form input.
* Do not rely on loose type comparisons (`==`) for security decisions. In older versions of PHP, loose comparisons can cause unexpected type coercions. Use strict comparisons (`===`) instead.
* Do not store security-sensitive information such as roles, permissions, or authentication state in client-controlled serialized objects — keep these server-side.
* Even if integrity is verified, treat deserialized objects as untrusted until their contents have been validated against the application's expected logic.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://ganesha-hk.gitbook.io/cybersecurity-writeups/port-swigger-insecure-desiralization-labs/lab-2.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.