Abdiwali Ahmed Abdisalam*

summary

An Insecure Direct Object Reference combined with a broken business-logic check exposed other customers' sensitive data. The "access token" in the request was format-checked only — never actually tied to the authenticated user's record.

discovery chain

1. Recon. Downloaded every JS bundle on the target subdomains, hunting for API endpoints, base URLs, tokens, and query parameters.
2. Signal. The JavaScript revealed a backend base URL. Frontend requests carried ?n=<uuid> and nt — described in-app as access tokens for the data.
3. Hypothesis. Is n validated server-side, or merely required to look like a UUID?
4. Proof. Requests with no token, an all-zero UUID, and a random UUID all returned 200 OK with full data. A non-UUID value returned 400 "Unable to validate communication." — format-only validation.
5. Escalation. Reusing the same token against a different communication ID returned another customer's record — no valid token or auth required.

impact

Sensitive PII exposed cross-customer: customer names, holdings, a masked account identifier, and a full voting record — accessible with no authentication. Horizontal access is a proven primitive.

recommendation

Bind every token to the owning record and the authenticated user server-side, and authorize each object access against the session identity. Format validation is not authorization.

# 1 — no token
GET /api/communication?mid=0000...
HTTP/1.1 200 OK
{ "customer": "...", "holdings": "...",
  "voting_record": [ ... ] }

# 2 — invalid uuid → still OK
GET /api/communication?n=00000000-0000-0000-0000-000000000000
HTTP/1.1 200 OK

# 3 — non-uuid → rejected (format only)
GET /api/communication?n=not-a-uuid
HTTP/1.1 400 "Unable to validate communication."

summary

The production API server trusts any subdomain of the target domain for credentialed cross-origin requests. A single weak link in the subdomain attack surface unlocks full authenticated API access.

observation

A request carrying a subdomain Origin made the server reflect it and grant credentials; external origins received a no-credential wildcard response. Trust is deliberately scoped to all subdomains.

attack chain

1. Takeover. Find a dangling CNAME to a third-party service and claim the orphaned subdomain.
2. Payload. Host malicious JavaScript on the controlled subdomain.
3. Execute. The script makes credentialed cross-origin requests carrying the victim's cookies.
4. Pivot. The origin is trusted → full API access with the victim's session.

recommendation

Replace wildcard subdomain trust with an explicit allowlist of production origins. Validate CNAME records, monitor for dangling DNS, and treat every subdomain as a security boundary.

# request with subdomain origin
POST /api/auth/login HTTP/1.1
Host: api.target.com
Origin: https://evil.target.com
Content-Type: application/json
{"username":"test","password":"test"}

# response
HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://evil.target.com
Access-Control-Allow-Credentials: true

# external origin → wildcard, no credentials
Origin: https://attacker.com
Access-Control-Allow-Origin: *