hunting-host-header-and-url-parsing-trust

Hunting host header and URL parsing trust: when the app believes the request about its own name

An application often needs to know its own address, to put a link in an email or to decide where a request belongs. The easy way is to read it from the incoming request: the Host header, or a forwarded-host header a proxy added. But those are attacker-controlled, and a server that builds a password-reset link from the Host sends the victim a link pointing at the attacker's domain. A shared cache that keys on a header the origin reflects serves the poisoned response to everyone. A router that trusts a forwarded host reaches an internal virtual host. The related trap is URL parsing: when the component that checks a URL and the component that uses it disagree about where the host ends, an allowlist passes a URL that resolves somewhere else. The bug is trusting the request's account of the host, or one parser's reading of a URL, as if it were authoritative. You find it by tracing where self-URLs, cache keys, routes, and allowlists get their host.

When to use

• The app builds absolute URLs (reset, verification, invite links) from the request's Host or forwarded host.
• A shared cache or a router keys on, or routes by, the Host or a forwarded-host header.
• A redirect or fetch allowlist parses a URL, and different components may parse that URL differently.

Scope check

Test host and URL-parsing trust only against systems you own or are authorized to assess, on non-production infrastructure, using a benign host you control and benign markers rather than poisoning a live cache or sending real reset links to third parties. A confirmed cache-poisoning or reset-link case reaches other users, so keep every probe in scope and prefer an isolated instance. If you can't name the authorization, stop.

The loop

1. Establish where the host actually comes from first. For each place the app names itself, keys a cache, routes, or matches an allowlist, determine whether it uses a fixed configured base URL and a trusted parser, or derives the host from the incoming Host or forwarded header and parses the URL ad hoc. This is the false-positive killer: a service that builds links from a configured base and routes on a trusted value cannot be poisoned through the header, while one that reflects the request host can. Name the source of the host before crafting a request.