Exploiting HTTP redirect function via the Host header

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 poising 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.