Manipulating Host Headers – Not Anymore !

Introduction

Host header injections have been around for a while now, and sometimes the developer just does not know how to get rid of them! Configuring virtual hosts, adding host verification codes to redirection pages, etc. All of this can be time-consuming or stressful for some!

So, I will be explaining a simple technique that the developers can use to mitigate all the issues related to hosting header manipulation.

Let’s start with the basic understanding of Host header injection!

In simple words, Host header injection is to change the value of Host header in the request to any other domain. Then the server uses the modified Host value in common tasks like redirection links, sending emails, password reset links, etc., which can lead to a variety of attacks. Another possible injection technique for Host headers can be through X-Forwarded-Host header. In some configurations, this header might rewrite the value of Host header.

 

This is a sufficient overview of the attack possibilities! If you do like to read more, I have added some good links in the references mentioned below.

Now let’s see what we can do to protect against these attacks.

 

Apache

For Apache and it’s variants the best way to mitigate Host Header Injection is by creating Virtual Hosts entries in the configuration file (httpd.conf). If multiple domains/sub-domains are hosted on the same server, then multiple vhost entries can be created as shown in the below snippet.

 

<VirtualHost *:80> #Configures the first and default virtual host listening for ALL IPs on PORT 80. It is the default because it is the first.

       ServerName yourdomain.com

       ServerAlias www.yourdomain.com

       UseCanonicalName On # Forces apache to use ServerName mentioned above instead of HostName from client request.

       DocumentRoot /path/to/your/webroot/directory

</VirtualHost>

 

<VirtualHost *:80>   #Configures the second virtual host. [For second domain/ subdomain hosted on the same server (if any)].

       ServerName test1.yourdomain.com

       UseCanonicalName On

       DocumentRoot /path/to/your/webroot/directory/of/second/domain

</VirtualHost>

 

As an alternative for Apache and it’s variants I recently created a redirect rule that can be put in .htaccess or in httpd.conf files. These rules work based on a regular expression that will verify the value of Host header and if the value does not match the regex pattern then a redirection is performed to a predefined URL.

 

Note: ^([a-zA-Z0-9-_]{1,20}.){0,3}domain.com$ will allow subdomains till 3rd level and each subdomain name can be between 1 to 20 character length. If you have N levels of subdomains, then replace {0,3} with {0,N}. If subdomain name length is X character long (more than 20), then replace {1,20} with {1,X}.

 

RewriteEngine On

RewriteCond %{HTTP_HOST} !^([a-zA-Z0-9-_]{1,20}.){0,3}domain.com$

RewriteRule ^(.*)$ https://domain.com/ [R=301,L]

 

The above code snippet checks if the Host header is equal to domain.com or any subdomain of domain.com. If the Host header mismatches, then a 301 redirection to https://domain.com/ is performed.

Above is the case when the server is having only one main domain hosted. If there are multiple domains, then the following snippet can be used.

 

RewriteEngine On

RewriteCond %{HTTP_HOST} !^([a-zA-Z0-9-]{1,20}.){0,3}(domain1.com|domain2.com|domain3.com)$

RewriteRule ^(.*)$ https://domain1.com/ [R=301,L]

 

The above code snippet will match the Host value with domain1.com, domain2.com, domain3.com and all their subdomains. If mismatched, a 301 redirection response for domain1.com will be sent to the user. More domains can be added to this rule in a similar fashion.

 

Now, suppose X-Forwarded-Host header is used on the server. Then since these forwards are done by the server-side implemented technologies, the developers already know their addresses. So just like the above defined regex-based rules, a new rule can be set to check if this header is present with a valid address.

 

RewriteEngine On

RewriteCond %{HTTP:X-Forwarded-Host} !^$

RewriteCond %{HTTP:X-Forwarded-Host} !^([a-zA-Z0-9-_]{1,20}.){0,3}(domain1.com|domain2.com|domain3.com)$

RewriteRule ^(.*)$ https://domain1.com/ [R=301,L]

 

The above snippet checks if the X-Forwarded-Host header is present. Then checks if it matches the allowed addresses. In case of a mismatch, a 301 redirection is performed to domain1.com.

 

IIS

The above regex patterns can also be implemented in IIS, via URL redirect module.

Follow the below steps:

  1. Open URL Rewrite module. Then click on “Add Rules” and create a blank rule.

  1. Give a name to this rule, so that it can be identified later. In match, URL section set the pattern to (.*) which means everything. So, this rule will be implemented on all the URLs. Then in conditions section click on “Add” button. The Condition input is {HTTP_HOST}, check is “does not match the pattern” and the pattern is ^([a-zA-Z0-9-_]+\.)*domain\.com$. A more secure regex pattern to use is ^([a-zA-Z0-9-_]{1,20}\.){0,3}domain\.com$.
  2. Now in the action section, the action type is redirected, URL is https://domain.com/, and redirection type is 301. Then click on the “Apply” button.
  3. Final rule looks like this. In case, this rules needs to be implemented for multiple domains, then regex pattern will be ^([a-zA-Z0-9-_]+\.)*(domain1\.com|domain2\.com|domain3\.com)$. A safer version for this regex will be ^([a-zA-Z0-9-_]{1,20}\.){0,3}(domain1\.com|domain2\.com|domain3\.com)$

For X-Forwarded-Host the rule will be set like this:

  1. Condition input will be {HTTP: X-Forwarded-Host}, the check will be “Does not match the pattern”, and pattern will be ^$. 
  2. For second condition, condition input will be {HTTP:X-Forwarded-Host}, check will be “Does not match the pattern”, and pattern will be ^([a-zA-Z0-9-_]+\.)*(domain1\.com|domain2\.com|domain3\.com)$ and safer regex version will be ^([a-zA-Z0-9-_]{1,20}\.){0,3}(domain1\.com|domain2\.com|domain3\.com)$. 
  3. Finally, the rules will look as mentioned in the below screenshot.

 

That’s all that is needed to protect your application from host manipulations.

 

There is much more potential in redirect rules and these were just a few demonstrations. You guys can surely use them as it is or modifies them as per the need.

 

References

1) https://www.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/

5) https://technet.microsoft.com/en-us/library/cc753195(v=ws.10).aspx

6) https://www.acunetix.com/blog/articles/automated-detection-of-host-header-attacks/

7) https://stackoverflow.com/questions/43941048/prevent-host-header-attack

8)https://www.ibm.com/support/knowledgecenter/en/SSZLC2_7.0.0/com.ibm.commerce.admin.doc/concepts/csewebserverconsiderations.htm

 

 

 

Author


1 comment

Very useful article. I used it to handle a host header vulnerability in web environment.

Leave a Reply

Your email address will not be published. Required fields are marked *