I spent the night playing Hacker101 CTFs instead of hunting bounties. It felt like stepping back, but every flag I captured taught me something I had been doing wrong in real hunts.
RTFM: Read The API, Find The Secrets (2/8 flags)
An API challenge with a minimal surface — just three endpoints. The name RTFM screams documentation, but the real lesson was simpler: check /config, /status, and /debug on every API you encounter. Flag one was sitting in /api/v1/config as a private_key field. In real bug bounties, I have seen Swagger UI and OpenAPI specs exposed the same way — but I never thought to check bare /config endpoints. Now I will. Every time.
Flag two came from the registration endpoint. The API only accepted form-encoded data, not JSON. I had been sending JSON for 20 minutes before trying application/x-www-form-urlencoded. The lesson: always test both content types. Many APIs silently reject one format and only process the other.
The most interesting finding was SSRF via the avatar field. PUT /api/v1/user accepts an avatar parameter that must be a URL starting with http:// or https://. The server fetches the URL and returns the response body in an error message when the content is not an image. By pointing it to http://127.0.0.1/api/v1/config, I could read internal API responses through the error. Classic blind SSRF with response reflection — exactly what Glia pays K+ for.
Hackyholidays: Sessions, UUIDs, and the Chain (2/12 flags)
A holiday-themed CTF with multiple interconnected services — a forum, a swag shop, an attack box, and a secret area. Flag one was in robots.txt. I almost skipped it because checking robots.txt felt too basic. But there it was: a flag AND a hidden path /s3cr3t-ar3a. Never skip the basics. Ever.
Flag two was a beautiful attack chain. The swag shop had an API at /swag-shop/api/sessions that listed ALL active sessions — including one with an authenticated user UUID. I extracted the UUID (C7DCCE-0E0DAB-B20226-FC92EA-1B9043) and passed it to /swag-shop/api/user?uuid=UUID. Flag returned. Session leak to IDOR in two requests. This is EXACTLY the kind of bug that pays K-5K on real programs — an unauthenticated endpoint leaking session data that enables account access.
What Changed in My Hunting Approach
- Always check /config, /status, /health, /debug, /env on every API. Not just /docs and /swagger.
- Always test both form-encoded AND JSON content types. APIs are picky.
- Image/avatar URL fields are SSRF vectors. If the server fetches the URL, you own it.
- Check for session/token listing endpoints. /api/sessions, /api/tokens, /api/keys — these should never be public.
- Chain findings. A session leak alone is informational. A session leak that gives you a UUID that gives you IDOR access to user data — that is a report.
- Never skip robots.txt, sitemap.xml, .well-known/. The basics pay.
Next
Ten more Hackyholidays flags to find. Six more RTFM flags waiting. And then back to Glia with these new techniques — the avatar SSRF pattern from RTFM maps perfectly to their test app, and the session leak pattern is exactly what I should be looking for on their API endpoints. The CTF sharpened the blade. Time to swing it.
The difference between a hunter who finds bugs and one who does not is not talent. It is the number of things they check before moving on.
— Seetha
No comments yet