Misc — Hidden in Plain Sight

Category: Misc · Difficulty: Medium

Scenario

While inspecting network traffic in your browser's DevTools (Path 05's Browser DevTools Lab should feel very relevant right about now), you notice api.kashsec-labs.test returns a few nonstandard response headers on every request — the kind most people scroll straight past without a second look.

Provided data

Full response headers captured from a single request:

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
X-Request-Id: 8f2c1a90-44b1
X-Debug-Trace-A: S0FTSFNFQ3toMzRkZXJzX2M0bl9oMW
X-Debug-Trace-B: RlX3NlY3JldHN9
Server: nginx

Something about those two X-Debug-Trace headers seems out of place compared to the routine ones around them.

Your task

Find the flag hidden across these headers.

Hint 1

Standard headers like Content-Type, Cache-Control, and Server follow well-known, documented formats. X-Debug-Trace-A and X-Debug-Trace-B aren't real standard headers at all — the X- prefix is a longstanding (if deprecated) convention for custom, non-standard headers, often left behind by developers during debugging and forgotten before shipping to production.

Hint 2

Look closely at the character set inside both values — letters, numbers, no spaces or unusual symbols. That's the same encoding signature from the earlier Crypto challenge in this section. Try concatenating the two values together, in header order (A then B), before decoding anything.

Show full answer

The two nonstandard X-Debug-Trace headers each hold one half of a Base64-encoded string, split across two headers specifically to make it slightly less obvious at a glance than a single long value would be. Concatenating X-Debug-Trace-A directly followed by X-Debug-Trace-B gives the full Base64 string S0FTSFNFQ3toMzRkZXJzX2M0bl9oMWRlX3NlY3JldHN9, which decodes directly to the flag.

The flag

KASHSEC{h34ders_c4n_h1de_secrets}

Bonus round — a second data point, from a different response

You capture headers from a completely different endpoint on the same target, this time on a request that errored out:

HTTP/1.1 500 Internal Server Error
Content-Type: application/json
X-Powered-By: Express/4.18.2
X-Internal-Host: prod-api-worker-07.internal.kashsec-labs.local
Set-Cookie: debug_session=eyJhbGciOiJIUzI1NiJ9.eyJyb2xlIjoiYWRtaW4ifQ.abc123signature; HttpOnly

Hint

Compare what a "normal," properly-behaving production server should reveal to an outside client versus what these specific header values actually disclose about the server's internals — and consider why an error response, specifically, is a common place for this kind of unintentional leak.

Show answer

Three separate disclosures here, each worth flagging as a distinct finding in a real report: X-Powered-By reveals the exact backend framework and version (Express/4.18.2) — directly useful to an attacker for searching known CVEs, exactly the technology-fingerprinting risk from Path 11.1's tech-fingerprinting lesson. X-Internal-Host leaks an internal-only hostname (prod-api-worker-07.internal...) that should never be visible outside the company's own network — a classic sign of a load balancer or internal service passing through headers it should have stripped before the response reaches the public internet. And the debug_session cookie contains what looks like a JWT with a suspiciously named debug_session — worth decoding with the same technique from this section's JWT challenge, since a debug-labeled auth cookie left active in production is exactly the kind of forgotten artifact that becomes a serious vulnerability. Error responses (like this 500) are a classic place for exactly this kind of leak, since they're generated by less-tested code paths than the application's normal happy path, and developers debugging a crash often add verbose internal detail they forget to strip before shipping.

Why this matters beyond the CTF

Debug headers, verbose error responses, and forgotten X- prefixed headers are a genuinely common real-world information disclosure vector — internal hostnames, framework versions, stack traces, and even authentication debug tokens have all shown up in production response headers left over from a development or QA build. Path 11's web recon lesson specifically calls out checking every response header during reconnaissance, not just the body — this challenge is a compressed illustration of exactly why that habit pays off. Tools like Burp Suite's Proxy history (Path 11) make scanning every header across an entire session dramatically faster than manually inspecting each response in DevTools one at a time.

When testing any web application (with proper authorization), get in the habit of reviewing full raw HTTP responses — not just what renders on the page — for every request type: normal pages, API calls, error responses, and redirects. Debug artifacts like this challenge's headers tend to survive precisely because they're invisible unless someone deliberately looks.

Next up → Crypto — Break the XOR Cipher