# Host header attacks Heavily inspired by [PortSwigger - Web Security Academy - Host header](https://portswigger.net/web-security/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: ``` 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: website.com ``` Already compromised subdomain ``` GET /path HTTP/1.1 Host: .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: ``` Line wrappings (if just duplicating the host header gets blocked, try to indent one) ``` GET /path HTTP/1.1 Host: Host: website.com ``` Absolute URL ``` GET https://website.com/path HTTP/1.1 Host: ``` For more: [PortSwigger - Web Security Academy - Request smuggling](https://portswigger.net/web-security/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: ``` ## Exploitation [PortSwigger - Web Security Academy - Host header](https://portswigger.net/web-security/host-header/exploiting) ### Password reset poisoning > Manipulate a website into generating a password reset link pointing to a domain under the your control * See also [PortSwigger - Web Security Academy - Password reset poisoning](https://portswigger.net/web-security/host-header/exploiting/password-reset-poisoning) 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. * See also [PortSwigger - Web Security Academy - Web cache poisoning via the Host header](https://portswigger.net/web-security/host-header/exploiting#web-cache-poisoning-via-the-host-header) 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 * See also [PortSwigger - Web Security Academy - Accessing restricted functionality](https://portswigger.net/web-security/host-header/exploiting#accessing-restricted-functionality) 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 * See also [PortSwigger - Web Security Academy - Routing-based SSRF](https://portswigger.net/web-security/host-header/exploiting#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 * See also [PortSwigger - Web Security Academy - SSRF via a malformed request line](https://portswigger.net/web-security/host-header/exploiting#ssrf-via-a-malformed-request-line) --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://d4rk1337.gitbook.io/the-pentesters-cheat-sheet/exploitation/web/host-header-attacks.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.