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

# lab-4

## Arbitrary Object Injection in PHP

**Difficulty:** Practitioner

### Lab Description

This lab uses a serialization-based session mechanism and is vulnerable to arbitrary object injection.

**Objective:** Create and inject a malicious serialized object to delete the `morale.txt` file from Carlos's home directory. Source code access is required.

**Credentials:** `wiener:peter`

### Root Cause

The application deserializes user-controlled session data without validating the object type or ensuring it is the expected class. Because PHP's `unserialize()` accepts any serializable class that exists on the server, an attacker can replace the expected `User` object with an arbitrary `CustomTemplate` object.

The injected class contains a `__destruct()` magic method that automatically executes when the object is destroyed. This method calls `unlink()` using the attacker-controlled `lock_file_path` property — allowing arbitrary files to be deleted whenever PHP invokes the magic method during the request lifecycle.

### 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. In Burp's site map, find the URL `GET /libs/CustomTemplate.php`. Append a `~` to the end of the path and send the request to retrieve the PHP editor backup file and read the source code.
4. Analyse the source — the key function is:

   ```php
   function __destruct() {    if (file_exists($this->lock_file_path)) {        unlink($this->lock_file_path);    }}
   ```

   This deletes whatever file path is stored in `lock_file_path` when the object is destroyed.
5. Construct a malicious serialized payload targeting the `morale.txt` file:

   ```
   O:14:"CustomTemplate":1:{s:14:"lock_file_path";s:23:"/home/carlos/morale.txt";}
   ```
6. Encode the payload: Base64-encode → URL-encode.
7. Replace the session cookie with the encoded payload and send the request.
8. The `__destruct()` method fires during deserialization cleanup and deletes `morale.txt`. A `500` Internal Server Error response is expected — the file has been deleted and the lab is complete.

### Lesson Learned

* Never deserialize user-controlled data without verifying its integrity and expected type.
* Do not allow arbitrary object instantiation through deserialization. The application should only deserialize trusted data, or use safe serialization formats like JSON when object reconstruction is unnecessary.
* Magic methods such as `__destruct()`, `__wakeup()`, and `__toString()` must never perform security-sensitive operations using attacker-controllable object properties.
* Avoid performing file operations, command execution, or other privileged actions directly from magic methods unless the input has been strictly validated.
* Exposing source code through backup files (such as `*.php~`) gives attackers detailed knowledge of classes, magic methods, and application logic, making exploitation significantly easier. Remove all backup and editor-generated files from production servers.


---

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