> 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-3.md).

# lab-3

## Using Application Functionality to Exploit Insecure Deserialization

**Difficulty:** Practitioner

### Lab Description

This lab uses a serialization-based session mechanism. A certain feature invokes a dangerous method on data provided in a serialized object.

**Objective:** Edit the serialized object in the session cookie to delete the `morale.txt` file from Carlos's home directory.

**Credentials:** `wiener:peter` · Backup account: `gregg:rosebud`

### Root Cause

The application uses legitimate features — such as viewing profile images, deleting avatars on account deletion, or viewing reports — that rely on specific classes to handle file paths. If the attacker modifies the file path values inside the serialized cookie and the server deserializes the object without validating those paths, the modified path is passed directly to the class responsible for reading, writing, or deleting files. This allows the attacker to target arbitrary files on the server, leading to unauthorised file deletion, disclosure, or modification.

### Exploitation

1. Log in using `gregg:rosebud`.
2. Upload any `.png` image as a profile avatar.
3. Click the **Delete account** button and capture the request in Burp. Send it to Repeater.
4. Decode the cookie: URL-decode → Base64-decode → inspect the serialized object.
5. Find the `avatar_link` attribute (which holds the file path used to delete the avatar). Replace its value and update the string length:

   ```
   s:23:"/home/carlos/morale.txt"
   ```
6. Replace the `username` value and string length with:

   ```
   s:6:"carlos"
   ```
7. Re-encode the modified object: Base64-encode → URL-encode, then replace the cookie.
8. Send the request — the response will likely be a `500` Internal Server Error, but it may also leak Carlos's `access_token` in the error output.
9. If an `access_token` is disclosed in the error, replace the token in the cookie with Carlos's token and send again.
10. The `morale.txt` file in Carlos's home directory is deleted, completing the lab.

### Lesson Learned

* Never trust client-controlled serialized objects. Any attribute inside a deserialized object must be treated as untrusted input.
* Do not use object attributes from deserialized data directly in sensitive operations such as file deletion, reading, writing, or command execution.
* Always validate that file paths belong to the authenticated user and restrict file operations to expected directories using allowlists and canonical path validation.
* Security-sensitive values such as usernames, file paths, object identifiers, and access tokens must be obtained from trusted server-side state — never from client-controlled serialized objects.
* Avoid leaking sensitive information in error messages. Detailed exceptions, stack traces, object contents, or access tokens returned in `500` responses can give attackers additional leverage to extend or simplify an attack.


---

# 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-3.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.