host-header

Host Header Attack Detection

Overview

The host named in a request tells a server which site the client wants, and it is entirely under the client's control. Applications that treat it as if it were server-owned — building absolute links from it, comparing it against an internal name to grant access, passing it into a query or a command, or routing on it at a proxy — hand an attacker a lever on the whole request lifecycle, from the first hop that parses the request line to the last line of a generated email. The attacker is normally an unauthenticated remote party who changes one header, or supplies an override header the stack honours by default, and gains an attacker-controlled reset link that yields the victim's token, a response that carries their domain into other users' pages, access to functionality gated on an internal hostname, or a request made from a privileged network position to an internal address. This skill finds such trust by locating every place the host or an override header is read together with every configuration that resolves, validates, or routes on it, checking each candidate in parallel, and merging the results into <output_dir>/host-header-results.md.

What it is NOT

• Server-side request forgery (/websec:ssrf): the classic form is a URL parameter the application itself fetches. Here the request is made by an intermediary because of how it routes on the host, and the application may never see it. Test: does the outbound destination come from a value the application passes to an HTTP client, or from a proxy's routing decision? The former belongs to the sibling skill.
• Web cache poisoning (/websec:web-cache-poisoning): a host value reflected into a response that a shared cache then serves to others is that class — the host is only the input. Test: is the harm caused by storage and redistribution? If yes, classify it there; if the harm is the link in an email or the access decision, classify it here.
• Cross-site scripting (/websec:xss): host reflected into markup without encoding is a reflection bug; it becomes a host-header finding when the host is also the vehicle for a link, a decision, or a route.
• Access control (/websec:access-control): a missing ownership or role check is that class. Here the check exists but consults an attacker-controlled hostname.
• Open redirection (/websec:open-redirect): a redirect whose destination comes from a URL-shaped request parameter belongs there, even when the same handler also reads the host. Test: is the attacker-supplied value the destination the handler redirects to, or the authority the framework substitutes into an absolute URL it builds? Only the second is this class.
• Injection into a backend query or command (/websec:sql-injection, /websec:nosql-injection, /websec:os-command-injection): if the host value is concatenated into a query or a command, the sink skill owns the finding; note the header as the source and record it here only under "Also observed".
• Request smuggling (/websec:request-smuggling): smuggling desynchronises where one request ends and the next begins. The neighbouring shape here is a proxy assuming that every request on a reused connection targets the first request's host — related, but the mechanism is host validation, not length disagreement.
• Not a finding: a host reflected into an error page or a log line that reaches no link, decision, or route; a server that returns a default site for an unknown host without changing behaviour; absolute URLs built from a configured canonical origin even though the host is also read somewhere inert; an override header that a proxy in the repository demonstrably overwrites before the application sees it.