Host header injection
Some intercepting proxies use the Host header to determine the target IP address, making testing difficult. Burp Suite keeps the Host header and target IP address separate, which is crucial.
Supply an arbitrary Host header
Start by testing the effect of providing an arbitrary domain name in the Host header
Occasionally, you can still reach the target website with an unexpected Host header
Or get an invalid Host header error
Exploitation
Password reset poisoning
The website sends an email to the user that contains a link for resetting their password:
https://normal-website.com/reset?token=0a1b2c3d4e5f6g7h8i9j
.Intercept the HTTP request, change the Host header to a domain you control, then visit the vulnerable website and use the stolen token in the appropriate parameter
Accessing restricted functionality
Admin panel with host: Host: localhost
Accessing internal websites with brute-forcing
Bruteforce subdomain
Web cache poisoning via the Host header
Client-side vulnerabilities like XSS aren't exploitable if they're caused by the Host header, as attackers can't manipulate a victim's browser to generate a harmful host.
However, if the target uses a web cache, it may be possible to turn this useless Web cache poisoning
Routing-based SSRF
If load balancers and reverse proxies are misconfigured to forward requests based on an unvalidated Host header, you can exploit this to reroute requests to any system you choose -> exploit this to have access internal-only systems.
Detection
In the host header add your attacker.com
website. If it doesn't work try to identify private IP addresses anyway.
You can also brute force 192.168.0.0/16
, 10.0.0.0/8
, etc.
Connection state attacks
You may encounter servers that only perform thorough validation on the first request they receive over a new connection. So, you can potentially bypass this validation by sending an innocent-looking initial request then following up with your malicious one down the same connection.
Note: you need to set up a single connection.
Exploiting server-side vulnerabilities
E.g. SQLi, etc.
Bypass validation
Parsing flaws
Override headers (
X-Host
,X-Forwarded-Server
,Forwarded
, etc.). You can also find with param miner -> guess headers
Inject duplicate Host headers
Supply an absolute URL (many servers are also configured to understand requests for absolute URLs).
Officially, the request line should be given precedence when routing the request but, in practice, this isn't always the case
Try also change protocol
HTTP
,HTTPS
Add line wrapping
Some servers will interpret the indented header as a wrapped line and, therefore, treat it as part of the preceding header's value
If the front-end ignores the indented header, the request will be processed as an ordinary request for vulnerable-website.com
Now let's say the back-end ignores the leading space and gives precedence to the first header in the case of duplicates. This discrepancy might allow you to pass arbitrary values via the "wrapped" Host header
Other techniques you can find on the web "common domain-validation flaws"
Last updated