Host header attacks

Heavily inspired by PortSwigger - Web Security Academy - Host header

Probing

Arbitrary host header

Send an arbitrary host header and see if you can still reach the app

Check for flawed validation

If port is not checked, and non-numeric port can be supplied

GET /path HTTP/1.1
Host: website.com:<bad-stuff-here>

If subdomains are not checked properly Register a domain that ends with the same name as the target one

GET /path HTTP/1.1
Host: <another>website.com

Already compromised subdomain

GET /path HTTP/1.1
Host: <compromised>.website.com

Ambigious requests

If the different components of the app use different validation logic, you may be able to exploit that.

Duplicate host headers

GET /path HTTP/1.1
Host: website.com
Host: <bad-stuff-here>

Line wrappings (if just duplicating the host header gets blocked, try to indent one)

GET /path HTTP/1.1
    Host: <bad-stuff-here>
Host: website.com

Absolute URL

GET https://website.com/path HTTP/1.1
Host: <bad-stuff-here>

For more: PortSwigger - Web Security Academy - Request smuggling

Host override headers

Using X-Forwarded-Host, X-Host, X-Forwarded-Server, X-HTTP-Host-Override or Forwarded header

GET /path HTTP/1.1
Host: website.com
X-Forwarded-Host: <bad-stuff-here>

Exploitation

PortSwigger - Web Security Academy - Host header

Password reset poisoning

Manipulate a website into generating a password reset link pointing to a domain under the your control

  1. Ensure Burp is enabled (to record the http history)

  2. Do the whole password reset procedure once with your own account

  3. Check Burp's HTTP history and look for the request, that triggered the reset, send to Repeater

  4. Change the Host header* and resend the request

  5. Check if the password reset still works, and if the reset link in the email contains the modified host

* If you can't change the Host header, try other stuff like using X-Forwarded-Host header to inject your host. (see above)

Web cache poisoning

Normally reflected Host headers are not exploitable, but when they're returned in a cached response, we may be able to leverage this for client side attacks like XSS.

  1. Try to observe differences between initial and further (cached) requests, use a "cache buster" like appending a get parameter (e.g. ?asdf=1) to get a fresh, uncached request, just change the the param.

  2. See if any of the above vulnerabilities can be used in a cached response (and therefore enable you to target other users, e.g. using XSS)

Access control

If the Host header is used for access control, e.g. using localhost to access an admin panel, this may be exploited, by just changing the Host header accordingly and get access.

Routing-based SSRF

Using Burp Collaborator, placing it's url into the Host header, you can check if the app reaches out to it. If so, in the next step you can use private IP addresses in the Host header to try to access internal-only systems. If you don't already have discovered private internal IP addresses, you can try to brute-force standard private IP ranges using e.g. Burp Intruder.

SSRF via a malformed request line

PreviousFile uploadsNextClickjacking

Last updated