I am testing a web application and found a redirect function which seems to be insecure. If I visit a non-existing page, then I am getting redirected to login page of application. However the redirect function can be exploited by setting custom Host header:

GET /temp/temp/nonexisting HTTP/1.1
Host: www.someevilsite.com

The server the responds with:

HTTP/1.1 302 Found
location: www.someevilsite.com/login

And simply redirects me to evil page. If it is possible to forge a remote user's Host header, and make him click a custom URL, then the user can be redirected to evil page, and potentially get his password stolen.

However, I can't seem to come up with a scenario in which I can compromise user's Host header. Are there any ways to manipulate user's Host header, considering website is over HTTPs?

2 Answers 2


This is an old question, but for the sake of completeness, I'll add some thoughts.

The reference in term of hosts headers attack is Practical Host header attacks (2013) and is still valid.

Attackers would quite certainly use the absolute-uri trick to inject the bad header and be sure to reach the right virtualhost. But in some cases, this is not even required (as may be in your current application, where any request with any Host header is accepted given that the HTTP query is made on the right IP)

# instead of
  GET /uri HTTP/1.1
  Host: good.name.com
# they would use
  GET http://good.name.com/uri HTTP/1.1
  Host: evil.com

And this could be exploited in mainly 3 ways (mainly, but that's open to more ideas):

  • cache poisoning: if your application feeds the page with a domain taken from the request (when rebuilding absolute URLs in HTML links) then there's maybe a chance that these bad domains end in the cached version of the page for /uri. Quite hard to perform (the cache may end up caching the page as http://good.name.com/uri and not /uri.
  • bad links in email: say your application is sending a password reset one-time link, with the URL taken from the host header, then the attacker could hope that someone will click the link with evil.com domain. But it means someone clicking on a reset password email link without asking for a password reset (as the attacker performed the bad query)
  • CRLF injection, as with all injected headers, one goal could be to get a response where a very bad host entry (containing CRLF, or %0d%0a (\r\n)) would be reused without filtering on the response headers. Leading to headers injection in the response.

As @Steffen Ullrich noted there's no way to lead an innocent user to perform the attack (especially because the browser uses the hostname DNS resolution to find the IP of the web server). So the only victim seems to be the attacker. But anyway, the attack target is asynchronous. It's not like an XSS attack, the target is not the user receiving the response. In cache poisoning it's quite obvious (target is the cache), in password reset email is used to carry the attack to the victim, and in CRLF injection we enter the HTTP response splitting and HTTP smuggling zone, where consequences are quite tricky, but they can lead to cache poisoning, deny of service, socket poisoning, incomplete requests, etc. The target is a reverse proxy, and the attack will later expand to other users via this proxy.


You cannot send a custom Host header from the browser which means that you cannot exploit this by using a browser alone. And, since HTTPS is used you cannot mount a man in the middle attack to modify the Host header of an existing request. But even if HTTPS would not be used you gain not really anything new by modifying the Host header in the request since as a man in the middle you could already modify the Location header in the response anyway.

In summary, I doubt that the problem you've found can be used for anything malicious, at least not when using the browser as a client.

  • thanks for your insight. I am thinking that one scenario could be to trick user into somehow installing some browser plugin which might change Host header, but likelihood seems extremely low. Commented Jun 29, 2017 at 11:28
  • 4
    Then you can also trick the user into installing a browser plugin that does far more evil stuff.
    – Josef
    Commented Jun 29, 2017 at 12:06
  • @iain: to cite myself: you gain not really anything new by modifying the Host header in the request since as a man in the middle you could already modify the Location header in the response anyway Commented Jun 29, 2017 at 13:38

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .