Hi! Hope you guys are doing well. Today we will learn about Host header injection.

Let us consider this scenario. Suppose Alex wants to send a letter to his friend who lives in a building named as Skyline Apartments. So what are the details Alex needs to ensure that letter is delivered properly? Obviously the first thing which comes in our mind is the address of Skyline Apartments. But since many people are living in that apartment, Alex has to include more precise information like Room number of his friend so that letter can be delivered hassle free.

Same thing happens in web applications. Whenever a request for any website is made from browser, browser first resolves domain name being accessed to an IP address and then send a request to that address. But what if multiple websites are hosted on the same IP address?

This is where Host header comes in. This header is used by a web server to decide which website should process the received HTTP request. So whenever multiple websites are hosted on the same IP address, web server uses the value of this header to forward the HTTP request to the correct website for processing.

Reasons leading to Host Header Injection:

Any approach in the field of web application if not implemented properly can make room for several vulnerabilities. Same goes with the implementation of the Host header. If the application relies on the value of the Host header for writing links without HTML-encoding, importing scripts, deciding the location to redirect to or even generate password resets links with its value without proper filtering, validation and sanitization then it can lead to several vulnerabilities like Cache Poisoning, Cross Site Scripting etc.

ImpactTampering of Host header can lead to the following attacks:

1) Web Cache Poisoning-Manipulating caching systems into storing a page generated with a malicious Host and serving it to others.

2) Password Reset Poisoning-Exploiting password reset emails and tricking them to deliver poisoned content directly to the target.

3) Cross Site Scripting - XSS can be performed, if the value of Host header is used for writing links without HTML-encoding. For example Joomla used to write Host header to every page without HTML Encoding like this: <link href=”http://_SERVER['HOST']”> which led to cross site scripting.

4) Access to internal hosts-To access internal hosts.

Web Cache Poisoning using Host Header Injection:

A. Web Cache Poisoning using Single Host Header.

1) Go to the following URL in browser - billing.engineyard.com and intercept the request.

2) In the image below, we can see the response of original request. It can be observed that in response there is 301 redirection and location to which application is redirecting depends upon the value of Host header in request.

Note: 301 Moved permanently redirects the browser permanently to a different URL, which is specified in the Location header. The client should use the new URL in the future rather than the original.

3) On following the redirection, it can be seen that application is redirecting user to the Login page (https://billing.engineyard.com/login).

4) Now if we change the value of Host header in the request captured during first step to some malicious domain and forward it to the server. It may lead to Web Cache Poisoning as this value is not being validated on the server and the user will be redirected to http://www.evil.com.

Now whenever user tries to access billing.engineyard.com from his browser he will be redirected to evil.com since the web-cache has been poisoned as a result of Host header injection.

5) On following the redirection, we can see that we are being redirected away from the parent domain of the application to the malicious domain.

And using this method an attacker can manipulate the Host header as seen by the web application and cause the application to behave in unexpected ways.

B. Web Cache Poisoning using Multiple Host Headers:

Sometimes it is possible to perform cache poisoning by using multiple host headers. Like Varnish, a popular content delivery network uses the first occurrence of host header, Nginx uses the last occurrence of host header and Apache concatenates all host headers present in the request to determine the host header to use.

For example: We can poison an Nginx cache with URLs pointing at evil.com by making the following request:

GET / HTTP/1.1 

Host: www.example.com

Host: www.evil.com

C. Web Cache Poisoning using X-Forwarded-Host Header:

In some cases Host header injection is mitigated by prohibiting tampering of Host header. In that case if any request is made with tampered host header, application responds with error message like “404 Not Found”.

There is another way of bypassing arbitrary Host headers by using the X-Forwarded-Host Header. The X-Forwarded-Host HTTP header is used to forward the original Host header value to the origin server. X-Forwarded-Host header is very crucial HTTP header for determining which Host was originally used when there is a proxy or CDN between the client and origin server. This header is necessary for servers running behind a reverse proxy (such as nginx).

If a request contains the X-Forwarded-Host HTTP header a website would then use its value in place of the actual HTTP hostname. In cases where caching is enabled, this could allow an attacker to potentially embed a remote URL as the base_url for any site. This would then cause other visitors to the site to be redirected unknowingly.

Thus if an application fails to prevent user from using the X-Forwarded-Host header, it will effectively override the Host header.

Example:

It’s possible to make a request like:

GET /store/getting-started HTTP/1.1 

Host: www.instacart.com

X-Forwarded-Host: www.evil.com

In this case the web application handling www.instacart.com will receive this HTTP request but the value of the Host header will be www.evil.com.

Steps showing Host Header Injection by using X-Forwarded-Host:

1) Open the following URL in browser www.instacart.com/store/getting-started and intercept the request. It is observed that application is redirecting to https://www.instacart.com/ by using 302 redirection.

2) On following the redirection, it can be seen that application is redirecting user to the https://www.instacart.com/. Here in this application, tampering of Host header is properly mitigated as when anyone tries to send a request with tampered host he is shown with a message stating: “404 Not Found”.

3) Now add X-Forwarded-Host header in request which was intercepted in first step and set its value to evil.com. It is observed that the X-Forwarded-Host header effectively overrode the Host header and as a result, the user is redirected to evil.com.

4) On following the redirection it can be seen that user is being redirected to the malicious domain which was set using X-Forwarded-Host header.

Mitigations:

1) Host header injection can be mitigated by rejecting any request that doesn't match the target domain.

2) Validating Host header to ensure that the request is originating from that target host or not.

3) Host header injection can be mitigated in Apache and Nginx by creating a dummy virtual host that catches all requests with unrecognized Host headers.

4) By creating a whitelist of trusted domains during the initial setup of the application and mapping domains received in Host header of each and every request with it.

5) It is recommended to disable the support for the X-Forwarded-Host header and if can’t be disabled put proper security checks on it to prevent its tampering.

6) One should use secure server configuration.

References:

1) http://skeletonscribe.net/2013/05/practical-http-host-header-attacks.html/

2) http://carlos.bueno.org/2008/06/host-header-injection.html

3) https://www.silverstripe.org/download/security-releases/ss-2015-013/

4) https://www.keycdn.com/support/x-forwarded-host/

That's all for this article friends ! Please feel free to give feedback or suggest new topics for discussion.

And always remember "Anyone who stops learning is old, whether at twenty or eighty. Anyone who keeps learning STAYS YOUNG !" So keep learning !

Utkarsh Tiwari