Classic ASP: ServerVariables["HTTP_HOST"] forging

Question

According to this MSDN article https://msdn.microsoft.com/en-us/library/ms525396(v=vs.90).aspx these variables are set based on headers. I'm curious if the HTTP_HOST variable is spoofable. I've run a few tests that indicate it's not spoofable, but I'd like to be sure.

EDIT: For clarity, I'm curious if something like a server proxy, man in the middle, or just someone who knows how to use netcat could forge the appropriate headers in order to manipulate HTTP_HOST within my scripts.

Spoofable by which involved party? Are you wondering if a server or proxy or man in the middle can change it? — Chief Wiggum, Dec 04 '15 at 18:44
Have you looked at the following article: http://shiflett.org/blog/2006/mar/server-name-versus-http-host — Chief Wiggum, Dec 04 '15 at 18:49
I hadn't, that pretty much cleared up the misconception I was under. — TheMonarch, Dec 04 '15 at 18:53
@JamesBlond That article is to do with PHP not Classic ASP. An assumption is being made about how IIS handles those header values. — user692942, Dec 04 '15 at 19:04

score 1 · Accepted Answer · edited May 23 '17 at 10:27

Yes it is spoofable.

A malicious user for your website can set any host header they want in their HTTP request and the HTTP_HOST variable will reflect that:

GET / HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1)

The only caveat is that it must be bound on your webserver. For example, if you use an IIS webserver you specify which hosts your website is bound to. This can be blank for "any" or you can set it to a specific domain name. If the latter, then at attacker sending

GET / HTTP/1.1
Host: www.foo.com
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1)

to your example.com domain would not hit your example.com website but would hit the default IIS website if that itself was running and if this has a blank binding. If it wasn't running then an error is returned instead. These measures will protect you from spoofing in attacks such as cache poisoning or spoofing malicious password reset emails.

Also note that HTTPS sites do not use the host header. They either bind directly to a single IP, or they use Server Name Indication (SNI), which is sent as part of the TLS/SSL handshake to determine which website the request is made to. IIS 8 and above support SNI and this introduces a per binding certificate that is interpreted in the same way as the host header for plain HTTP. Note that this can be spoofed in the same way by an attacker at the browser end because they can send whichever domain name they want.

However, SNI information cannot be altered by a Man-In-The-Middle attacker like it can with a plain HTTP request. This is because the browser will check that the domain name matches the requested site and will warn the user if this is not the case. There is no such authentication with plain HTTP. The only attack I could think of in a MITM scenario with HTTPS is one where wildcard certificates are used and that a MITM could make the user hit a different site than expecting with no browser warning. However the TLS handshake FINISHED message hash would not calculate if this had been altered by a MITM, so that should mitigate this attack.

Classic ASP: ServerVariables["HTTP_HOST"] forging

1 Answers1