Love Letter Locker - TryHackMe Writeup | IDOR to Read Other Users' Letters

##TryHackMe Room — Love Letter Locker (Love At First Breach 2026)

Use your skills to access other users' letters.

Love Letter Locker lets users register, log in, and store private love letters. The challenge hint said something like "Every love letter gets a unique number in the archive" — which suggested that letters were identified by a numeric ID and that this ID might appear in the URL or in API calls. If the server did not check that the current user owned the letter for a given ID, we could read other users' letters by simply changing the ID (classic IDOR). My goal was to register, create a letter to see how the ID was used, then try accessing other IDs (e.g. 1, 2) to see if the server enforced ownership. This writeup documents that process and how the missing authorization check led straight to the flag.

##Overview

Item	Detail
Goal	Read another user's private letter containing the flag
Attack chain	Register, create letter, observe numeric ID, enumerate other IDs, read letter, flag
Key concepts	IDOR, predictable object references, missing authorization checks

##Methodology (high level)

Phase	Goal
Recon	Understand routes and behavior
Mapping	See how letters are referenced (e.g. /letter/ID)
Testing	Try accessing other IDs with the same session
Exploitation	Read a letter that belongs to another user
Validation	Capture the flag

##Reconnaissance and registration

The application was at http://<TARGET_IP>:5000 with /register and /login. I registered a new user and logged in. After login I was redirected to /letters — the "my letters" dashboard. The page showed something like "Total letters in Cupid's archive: 2" while my own account had 0 letters. So letters were stored in a shared store (not per-user tables in a way that hid other users' data), and the total count suggested at least two letters already existed — likely with IDs 1 and 2. That made it plausible that letter IDs were numeric and sequential, and that we might access them by requesting /letter/1, /letter/2, etc., if the app used that kind of URL scheme. I created a letter to see how the app referred to it.

##Creating a letter and discovering the ID

I created a letter (e.g. simple title and body; I also tried script tags to check output encoding — it was escaped, so XSS was not the intended vector). After saving, Burp showed a redirect like:

http

GET /letter/3

So my letter was at /letter/3. That implied: letters are identified by numeric IDs; IDs are sequential or predictable; the URL exposes the object reference. So I tried /letter/1 and /letter/2 with the same session to see if the server enforced ownership.

##Key concept: IDOR

IDOR (Insecure Direct Object Reference) occurs when the app exposes internal object IDs (e.g. 1, 2, 3) in URLs and the server does not verify that the current user is allowed to access that object. Then anyone who can guess or enumerate IDs can read (or modify) other users' data — horizontal privilege escalation. No special payloads; just change the ID.

##Exploiting IDOR

I requested:

http

GET /letter/1 HTTP/1.1
Host: <TARGET_IP>:5000
Cookie: session=...

The server returned 200 with the content of letter 1 — another user's private letter. There was no ownership check. In the body I found the challenge flag in the usual THM format.

##Flag

text

THM{*redacted*}

(Replace with the actual flag when you solve the room.)

##Attack chain summary

Step	Action
1	Register and log in
2	Create a letter
3	Observe redirect to /letter/3 (or similar)
4	Infer numeric, predictable IDs
5	Request /letter/1 (and optionally 2)
6	Read another user's letter; capture flag

##Pitfalls and notes

>Chasing XSS: I tested script tags in title/body; the app escaped output, so XSS was mitigated. The intended flaw was authorization, not input sanitization.
>Stopping at "my" letter: The vulnerability is in access control. Always test: "Can I access the same resource with a different ID?"

##References

This writeup is part of my Love At First Breach 2026 event writeups.