TreaPortal

Challenge Overview

Flag

Reconnaissance / Analysis

• Opened the web app by IP and viewed the page source.
• In init.ts (TypeScript frontend init) the flag field is referenced, but it is a value loaded only in the production build — i.e. a backend field, not something present in the client bundle.
• Created a user account on the site.
• Observed an access-control restriction: you can look up your own profile, but not anyone else's.
• A direct SQL injection on the lookup field did not work — blocked by the access-control check, not by the injection itself.

Exploitation

The lookup endpoint /api/user/ reads a username query parameter. Sending the parameter twice makes the access-control check and the database query disagree about which value to use (HTTP Parameter Pollution). The first username carries the SQLi payload; the second is empty — the authorization check passes while the query is injected.

Step 1 — Craft the request (HPP + SQLi)

Intercept the self-lookup request in Burp Suite and change the request line to:

GET /api/user/?username=%27%20or%20flag%21%3D%27&username= HTTP/1.1

URL-decoded, the first parameter is:

username=' or flag!='

' or flag!=' breaks out of the string literal and ORs a condition on the flag column, so the query returns every row whose flag field is non-empty — i.e. the record(s) containing the flag.

Result

The flag is returned in the response body, visible in the browser's Network tab (DevTools inspect tool).

FLAG FOUND

Techniques Demonstrated

1. Source analysis (init.ts) revealing a prod-only flag field
2. Broken object-level access control (self-only lookup)
3. HTTP Parameter Pollution (duplicate username parameter)
4. SQL injection (' or flag!=')

Tools Used

Browser (view-source + DevTools Network), Burp Suite