Http redirect using Location, but using falsely supplied data from host header

Question

If I have a domain www.mysite.com, and I am making a request to www.mysite.com on port 80 using telnet, but I send a host header with another domain name(www.wrong-domain.com), but the server doesn't correctly verify if the host header contains it's own domain, and initiates a redirect response with Location header set to the user supplied domain from the "host" header.

Can this lead to any specific attack scenario because of this?

I am not looking at HTTP splitting type of attack, since the server is not vulnerable to it, but can this lead to other kinds of attacks? My first thought was something like redirect amplification, similar to dns amplification, but that doesn't look like possible.

Below is the output from the telnet. The server doesn't verify if the host header contains its own domain, and uses it to create the Location header in the response.

P.S.: The site is not vulnerable to HTTP splitting attacks.

telnet www.mysite.com 80 GET / HTTP/1.1 host: www.wrong-domain.com

HTTP/1.1 302 Found Server: Apache-Coyote/1.1 Cache-Control: private Expires: Thu, 01 Jan 1970 00:00:00 UTC Location: https://www.wrong-domain.com/ Content-Length: 0 Date: Sun, 11 Jan 2015 15:57:26 GMT

Answer 1

The web server doesn't know what DNS lookup you did to get to it. As far as the server is concerned you're only ever doing something like telnet 1.2.3.4 80 GET / HTTP/1.1 host: www.wrong-domain.com or telnet 1.2.3.4 80 GET / HTTP/1.1 host: www.mysite.com

In this context any domain in the host header is not right or wrong. The server reads that header and handles the request with a specific configuration if available or with a default configuration if not (this is what allows serving multiple domains from the same server/ip address).

Unless I'm missing something the redirect response here is not really a problem, you requested wrong-domain not mysite and the server told you that the content you requested might exist somewhere else.

That said it is important to make sure that the default configuration on the server does what you want it to do, because a misconfiguration could leak information that you do not intend.

In this case it looks like the default configuration of your server is set to redirect all requests to HTTPS. Which is ok, but depending on what your goals for the sever are, a better way to handle it might be to have the server redirect any unknown domains to a known domain, or perhaps to just drop the connection. Thereby either reducing additional traffic to the server or at least directing it to somewhere useful.