My First CTF: A Beginner's Web Exploitation Writeup

I spent about two hours on this challenge before I understood what was happening. The process was useful, so I wrote it down.

The challenge

A small web app let you view your own profile at /profile?id=104. Changing the number changed nothing at first glance — until I noticed the response time was slightly different for IDs that existed versus IDs that didn't.

Step 1 — Mapping the attack surface

I first used the app normally and noted every endpoint that accepted an ID:

• /profile?id=
• /messages?user=
• /invoices?ref=

The important question was whether the server checked that the requested ID belonged to the logged-in user.

Step 2 — Testing the assumption

The working theory was that the app trusted the ID in the URL without checking it against the logged-in session. That is the basic pattern behind an IDOR (Insecure Direct Object Reference).

curl -s "https://target.ctf/profile?id=104" -H "Cookie: session=mine"
curl -s "https://target.ctf/profile?id=105" -H "Cookie: session=mine"

Both requests returned 200 OK with different user data, confirming that the server did not enforce an ownership check.

Step 3 — Finding the flag

Checking IDs by hand would take longer, so I used a short loop:

for i in $(seq 90 120); do
  curl -s "https://target.ctf/profile?id=$i" | grep -o "flag{.*}"
done

The flag appeared in a profile bio field that should not have been accessible.

What I took away from this

• Check the ordinary endpoints. The bug was in a normal-looking profile URL, not a complicated feature.
• Pay attention to small differences. The response timing was enough to suggest that the server treated existing and missing IDs differently.
• Automate repetitive checks. The loop saved time, but understanding the authorization flaw was the important part.

Next, I want to test the app's file-upload endpoint and see how well it validates file types.