Host Header Poisoning

Description

Host Header Poisoning is a web application vulnerability that occurs when an application trusts and uses the HTTP Host header without proper validation. The Host header specifies the domain name of the server and is typically used for virtual hosting, where multiple websites are hosted on a single server.

When applications improperly handle this header, attackers can manipulate it to redirect users, poison caches, or bypass security controls. The vulnerability is particularly dangerous because the Host header is often considered trustworthy by developers and is used in critical security functions such as generating absolute URLs, validating origins, and constructing email notifications.

Impact

• Password reset poisoning: Manipulated password reset links redirect users to attacker-controlled domains, enabling credential theft.
• Cache poisoning: Malicious content can be cached and served to other users accessing the application.
• Server-Side Request Forgery (SSRF): Force the server to make requests to internal systems or external attacker-controlled domains.
• Authentication bypass: Circumvent authentication mechanisms that rely on host-based validation.
• Business logic bypass: Defeat security controls that depend on hostname validation.
• Email header injection: Inject malicious content into email notifications sent by the application.

The vulnerability enables both direct exploitation and chaining with other attack vectors for broader system compromise.

Common Examples

• Password reset emails containing links to evil.com instead of the legitimate domain
• Cached responses poisoned with attacker-controlled content served to legitimate users
• Internal API calls redirected through manipulated Host headers
• Authentication systems bypassed by spoofing trusted hostnames
• Email notifications with injected headers leading to spam or phishing campaigns
• SSRF attacks against internal services using manipulated Host headers

Detection

Host Header Poisoning can be detected through various testing approaches:

• Manual testing: Modify the Host header to arbitrary values and observe application behavior
• Automated scanners: Tools like Burp Suite, OWASP ZAP can detect improper Host header handling
• Password reset testing: Request password resets with modified Host headers and check email links
• Cache analysis: Monitor for unexpected cached responses when Host headers are manipulated

Example test cases include setting the Host header to:

• evil.com
• localhost
• internal.company.com
• Invalid formats like host:[email protected]

Remediation

Prioritized steps to mitigate Host Header Poisoning vulnerabilities:

• Implement Host header validation:

  • Maintain a whitelist of allowed hostnames and validate incoming Host headers against this list.
  • Reject requests with invalid or unexpected Host header values.
  • Use strict hostname validation that includes checking for proper domain formats.

• Use absolute URLs instead of Host-dependent URLs:

  • Configure applications to use predefined, absolute URLs for critical functions like password resets.
  • Avoid dynamically constructing URLs based on the Host header value.
  • Store trusted domain names in configuration files rather than deriving them from user input.

• Configure web server properly:

  • Set up virtual hosts to reject requests with unrecognized Host headers.
  • Configure the web server to return a default page or error for invalid hostnames.
  • Use server-level redirects to enforce canonical domain names.

• Implement additional security headers:

  • Use X-Forwarded-Host header validation when behind reverse proxies or load balancers.
  • Implement Content Security Policy (CSP) to restrict resource loading from unauthorized domains.
  • Set appropriate Referrer-Policy headers to control referrer information leakage.

• Framework-specific mitigations:

  • Django: Ensure ALLOWED_HOSTS setting is properly configured.
  • Express.js/Node.js: Implement middleware to validate Host headers.
  • ASP.NET: Use URL validation and avoid trusting HttpContext.Request.Url.Host.

Example Configurations

• Nginx

  server {
    listen 80 default_server;
    server_name _;
    return 444;  # Drop connection for invalid hosts
  }
   
  server {
    listen 80;
    server_name example.com www.example.com;
    # Application configuration
  }

• Apache

  <VirtualHost *:80>
    ServerName example.com
    ServerAlias www.example.com
    # Application configuration
  </VirtualHost>
   
  <VirtualHost *:80>
    ServerName _default_
    DocumentRoot /var/www/html/error
    # Catch-all for invalid hosts
  </VirtualHost>

• Application-level validation

  # Python/Django example
  ALLOWED_HOSTS = ['example.com', 'www.example.com']
   
  def validate_host(request):
      host = request.get_host()
      if host not in settings.ALLOWED_HOSTS:
          raise DisallowedHost("Invalid host header")

Verification

To confirm remediation:

• Test with various malicious Host header values and verify they are rejected or sanitized.
• Confirm password reset emails contain only trusted domain links.
• Verify cached responses are not poisoned with attacker-controlled content.
• Check that internal APIs cannot be accessed through Host header manipulation.

References

• PortSwigger Web Security Academy: Host Header Attacks
• OWASP: Host Header Injection
• CWE-20: Improper Input Validation

Next Steps

If Host Header Poisoning vulnerabilities are found during testing:

• Immediately implement Host header validation and whitelisting.
• Review all functions that use the Host header for URL generation.
• Consider related issues:
  • Verbose Error Messages
  • Directory Listing Exposure

---

Takeaway: Host Header Poisoning is a vulnerability that can lead to account takeover and cache poisoning. Implementing proper Host header validation should be a standard security control in all web applications.