> For the complete documentation index, see [llms.txt](https://ganesha-hk.gitbook.io/offensive-security-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/offensive-security-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 by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://ganesha-hk.gitbook.io/offensive-security-writeups/port-swigger-insecure-desiralization-labs/lab-3.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

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.