Host Header Manipulation Vulnerability
Security is a vital element when developing web applications. Most developers take security as a priority and work to make sure that their solution is secure. But there are certain vulnerabilities that are not that severe, but not paying attention to them can be lethal.
One such vulnerability is the host header manipulation vulnerability. There are many cases, in developing web applications where the developers trust the host header provided by the request for various activities. These include even important activities such as generating scripts, links which also include password reset links :o.
Although this host header is added to the request automatically (being the main reason for developers to trust this value), attackers can manipulate this value as they please. Therefore it is not advised to trust this value.
There are two main types of attacks that can be orchestrated using this vulnerability.
- Password reset poisoning
- Cache poisoning
Password reset poisoning
When a developer trusts this value, it can be used to generate a link to reset the password of a user. For instance, consider the following scenario:
When a user needs to reset a password, the developer generates the link to reset the password by populating the following template:
$resetPasswordURL = “https://{$_SERVER[‘HTTP_HOST’]}/reset-password.php?token=12345678-1234-1234-1234-12345678901”
And the token given here is a one time token so that the user will not need to enter the previous password once again. In this case, the attackers can easily rest the password of the said user.
More information on this can be found here: https://www.acunetix.com/blog/articles/password-reset-poisoning/
Web Cache Poisoning
Web cache poisoning is when an attacker manipulates the cache to serve poisoned malicious content to any party who requests pages. Such attacks are often difficult as all modern standalone caches are Host-aware.
More information on this can be found here: https://www.acunetix.com/blog/articles/what-is-web-cache-poisoning/
Remedies
It is always advised not to trust any header values sent by the client for critical operations. You can fetch the hostname by storing some kind of configuration. If you must use the host header as a mechanism for identifying the location of the web server, it’s highly advised to make use of a whitelist of allowed hostnames.
The best remedy is to create a dummy virtual host that catches all requests with unrecognized Host headers. Ideally, this redirection can be pointed at some error page. Steps to get this done is given below:
Apache: http://httpd.apache.org/docs/trunk/vhosts/examples.html#defaultallports
Nginx: https://www.nginx.com/resources/wiki/start/topics/examples/server_blocks/
