Trust Fall Writeup - PatriotCTF 2025

The challenge provided a small product‑catalog web application. At first glance, it behaved normally: products were listed on the main page, and each product linked to a detail view. Every request sent a hard‑coded token:

Authorization: Bearer trustfall-readonly

This was suspicious: real applications never bake tokens into client‑side JavaScript. Hard‑coded tokens often indicate that the challenge designer wants players to investigate the backend API directly.

---

Reconnaissance

The front‑end code revealed two interesting details:

1. The application fetched data from the following endpoints:

   • /api/products
   • /api/products/<sku>

2. There was a link to /admin, which always responded with 403 for our read‑only token.

While exploring the product API, nothing unusual appeared — just harmless product data with a field named updatedBy.

But the presence of that numeric user identifier suggested the existence of a user system behind the scenes.

---

Discovering the User API

By experimenting with likely paths, one of the key discoveries was that the backend exposed:

/api/users/<id>

Requests using the read‑only token were not restricted at all. For example, accessing:

/api/users/1

returned:

{
  "id": 1,
  "username": "inventory-analyst",
  "role": "inventory",
  "flag": null
}

A second user (id = 2) also contained flag: null. That meant the flag likely lived on another user profile. At this point the vulnerability was clear:

The API leaked user data by ID without any authorization checks. This is a classic Insecure Direct Object Reference (IDOR).

---

Enumerating User IDs

Given that user IDs were simple integers, the next logical step was to enumerate additional IDs.

Testing:

/api/users/0

returned:

{
  "id": 0,
  "username": "root",
  "role": "superuser",
  "flag": "PCTF{authz_misconfig_owns_u}"
}

This profile contained the challenge flag.

---

Root Cause Analysis

The vulnerability existed because:

• The backend returned user objects solely based on the numeric ID in the path. • No authentication or role‑based access control was enforced. • The read‑only bearer token was accepted for every user profile.

As a result, anyone with access to the client‑side JavaScript (including challenge players) could enumerate user IDs and extract sensitive information.

---

Flag

Obtained from:

/api/users/0

---

Conclusion

The Trustfall challenge demonstrates how dangerous IDOR vulnerabilities can be. Even when an application appears harmless, exposing predictable object identifiers without proper authorization checks can leak sensitive data, including administrative secrets and flags.

This challenge reinforces a core principle in secure backend design:

Never trust client‑side tokens, and never expose internal objects without verifying who is requesting them.