What is an HTTP Host Header?
The HTTP Host header is a mandatory header field in an HTTP request that specifies the domain name of the web server being requested. It allows a single server to host multiple domains and respond to requests for each of them appropriately. It allows the client to specify the intended destination of the request when communicating with a web server that hosts multiple websites on a single IP address. When a client sends an HTTP request to a server, it includes the Host header to indicate the specific domain or IP address it wants to access. This is particularly useful in situations where multiple websites are hosted on the same server, as the server can use the Host header to determine which website the client is trying to reach and route the request accordingly.
When a client sends an HTTP request to a server, it includes a Host header that identifies the domain name of the server that it is attempting to connect.
For example, if a client requests a web page from “example.com”, the Host header in the request will be “example.com”.
GET /index.php HTTP/1.1
Host: example.com
The server uses this information to determine which website the client is requesting and then serves the appropriate content.
Purpose of Host Header: –
The Host header is especially important for virtual hosting, where a single web server hosts multiple websites with different domain names. Using the Host header to identify the requested domain, the server can route the request to the correct virtual host and serve the appropriate content. The Host header is also used in some other scenarios, such as when a web server acts as a reverse proxy, forwarding requests to a back-end server based on the Host header value.
Why does Host Header Injection Attacks occur: –
HTTP Host header attacks exploit vulnerable websites that handle the value of the Host header in an unsafe way. If the server implicitly trusts the Host header and fails to validate, an attacker may be able to use this input to inject a malicious host in the header that manipulates server-side behaviour.
In common, it has the ability to tamper or change the functionality of the application behaviour using the Host: Header value.
Tampering of Host Headers leads to some kind of vulnerabilities such as:
- Web Cache Poisoning
- Password Reset Poisoning
- Server-Side Request Forgery
- Open Redirection
Web Cache Poisoning:
Manipulating caching systems into storing a page generated with a malicious Host and serving it to others. we may find that the Host header is reflected in the response markup without HTML encoding or even used directly in script imports. It’s highly possible for a web cache poisoning and leads to client-side vulnerabilities such as Reflected Cross-site scripting.
Reflected client-side vulnerabilities, such as XSS, are typically not exploitable when caused by the Host header. There is no way for an attacker to force a victim’s browser to issue an incorrect host in a useful manner.
However, if the target uses a web cache, it may be possible to turn this useless, reflected vulnerability into a dangerous, stored one by persuading the cache to serve a poisoned response to other users.
Set appropriate Cache-Control headers on web server responses. Utilize directives such as “private,” “no-store,” and “no-cache” to control caching behaviour and prevent sensitive information from being stored in caches.
Do not support additional headers that may facilitate this type of attack. E.g., “X-forwarded-Host” Header. Remember to disable this if enabled by default.
GET /cbi=test<script>alert(1)</script> HTTP/1.1
Host: example.com
X-Forwarded-Host: attacker.com
Cache hits the browser, and an alert executes
HTTP/1.1 200 OK
X-Cache: hit
Password Reset Poisoning:
If the Host Header value is used to build a URL for password reset links and account activation links, password reset poisoning attacks are mostly possible. Password reset functionality abuse is the most common use of Host Header attacks. Exploiting password reset emails and tricking them into delivering poisoned content directly to the target.
GET /forget-password HTTP/1.1
Host: attacker.com
As a result, the victim will receive a password reset link as
https://attacker.com/password-reset-token=XXXXXXXX
To prevent password reset poisoning attacks via host header attacks, they should validate and sanitize all user input, including HTTP headers.
Server-Side Request Forgery
Server-Side Request Forgery (SSRF) is an attack in which an attacker can trick a web application into making unauthorized requests on their behalf. One common technique used to execute SSRF attacks is manipulating the “Host” header of an HTTP request.
Exploiting Server-side request forgery by changing the host to any internal IP or local host address and accessing the internal files. Header manipulation can then allow an attacker to specify sites that should not be accessible from the outside.
GET /admin/secret_files HTTP/1.1
Host: 192.168.0. $0$
Host: localhost
To prevent SSRF attacks via the “Host” header, web developers should validate and sanitize all user input, including HTTP headers. Additionally, it is recommended to configure firewalls, network infrastructure, and web servers to restrict outbound traffic to only known and trusted IP addresses and domains. This can help prevent attackers from ex-filtrating sensitive data or executing unauthorized requests.
Open Redirect:-
Open redirection is a vulnerability in which an attacker can manipulate a website’s URL parameters to redirect users to a malicious website. This vulnerability can be exploited using various techniques, including host header attacks.
Host header attacks can be used to modify the “Host” header of a request to redirect users to a malicious website. The attacker can craft a request with a manipulated “Host” header that points to a domain they control. If the website does not properly validate the “Host” header, it may use it to construct a redirect URL that includes the attacker’s domain.
To protect against open redirection attacks, web developers should also consider implementing additional security measures, such as limiting the use of external redirects and implementing a proper login flow. Should follow a strong redirection policy.
GET /index.php HTTP/1.1
Host: example.com -> attacker.com
By changing the host header, the site is redirected to the attacker.com
Manipulating HTTP Host Header:-
Manipulate Host headers by using host override headers. The web server might be configured to accept the X-Forwarded-Host header and use its value to rewrite the original Host header. Then send requests like the following, where example.com is the legitimate host to replace with the malicious attacker.com
GET /index.php HTTP/1.1
Host: example.com
X-Forwarded-Host: attacker.com
Also, it is possible to use these headers to manipulate the host.
- X-Forwarded-For:
- X-Forwarded-Host:
- X-Originating-IP:
- X-Remote-Addr:
- X-Remote-IP:
- X-Client-IP:
- . . . .
Supplying duplicate Host headers: if systems differ in how they interpret multiple Host headers in one request, a Host header injection vulnerability is possible.
GET /index.php HTTP/1.1
Host: example.com
Host: attacker.com
Another way is by using the host as a subdomain of the main host.
GET /index.php HTTP/1.1
Host: example.com
Host: attacker.example.com
Mitigations of Host Header Injection Attacks:
There are several mitigations that can be used to prevent or reduce the impact of Host Header Injection attacks.
- Validating user input: Web application developers should ensure that all user input, including the Host header, is properly validated and sanitized before processing.
- Using a whitelist: Web application administrators can create a whitelist of trusted domain names that the application will accept requests from. If a request is received with a Host header that does not match any of the trusted domains, it can be rejected.
- Removing or disabling caching: Web application administrators can remove or disable the caching of responses to prevent attackers from injecting malicious content into the cache via the Host header.
- Implementing HTTP Strict Transport Security (HSTS): HSTS is a security mechanism that allows web application administrators to enforce the use of HTTPS on their websites. Using HSTS, administrators can prevent attackers from intercepting or modifying the Host header via a Man-in-the-Middle (MitM) attack.
