B - Production Support » BSN CDB Support

In many cases, developers are trusting the HTTP Host header value and using it to generate links, import scripts and even generate password resets links with its value. This is a very bad idea, because the HTTP Host header can be controlled by an attacker. This can be exploited using web-cache poisoning and by abusing alternative channels like password reset emails.

Below are some potential scenarios an attacker can exploit the vulnerability.

- By supplying a malicious host header with a password reset request, it may be possible to generate a poisoned password reset link. 
- If the application is not externally accessible or uses IP-based access restrictions. Attackers can use DNS Rebinding to bypass any IP or firewall based access restrictions that may be in place, by proxying through their target's browser. Note that modern web browsers' use of DNS pinning does not effectively prevent this attack.
- Depending on the configuration of the server and any intervening caching devices, it may also be possible to use this for cache poisoning attacks.
- Additionally, it may be possible to directly bypass poorly implemented access restrictions by sending a Host header of 'localhost'.

Solution Given :

It is not recommended to use host header within the application function that involve security checking or business flow.

However, if the host header value is required, it's highly advised to make use of a whitelist of allowed hostnames or use the SERVER_NAME instead of the host header.