Preventing host header attack

Gena, I think there's an easy answer for you. Just be sure to define a host name in the bindings for all your IIS sites. That may be easier said than done for some folks, but it should prevent the problem. Let me elaborate.

Though first I want to offer a clarification. You refer to this attack as being one "where X-Forwarded-Host was modified to trigger redirect to potentially malicious site." That's not my understanding of what this attack is about. If you read any of various resources about the attack, they discuss how an improperly configured web server could lead to an UNINTENDED site processing the request, not so much a "malicious" one. But the handling of a request by an unexpected site could indeed lead to something malicious (with a request getting to a site that was not as hardened as others were).

What many folks do who use IIS (if not most folks, from my experience) is they just leave the IIS "default web site" defined, whose bindings are set to have NO hostname (and to listen to requests for ANY ip address that gets into the server). And they may or may not bother to add other sites, and those may themselves have host header values and IP addresses, which will be matched on an incoming request. 

The way things work is that if a request comes into IIS, then whatever host header is sent with it (and whatever IP address it came into the server requesting) is compared to all those sites' bindings, and if any site matches the given host header and/or IP address, then that site will run that request. (And if a given site matches the IP address used but that site was left to have NO host defined in its binding, then again that site WILL process that request, assuming no other site was matched for that host/ip address.)

And to be clear, when I refer to the IP address here, this is NOT about the IP address FROM WHICH a request comes. It's only about the IP address used to REQUEST THE SITE. Usually that is determined by a DNS lookup (in the client making the request) where it finds your site and what IP address that domain "lives at", and the request (with that typed in domain and that looked up IP address) is then passed on to the server. Of course, all that can be faked, thus the "attack" problem.

As for that "default site" (whether it has that site name, or some other site name), it's especially likely to be the cause of such problems. It's set (by default) to have NO host header and * for its ip address. And what that means is that if a request comes and no sites match that requests's host header and IP address, then this "default" site will handle it.

But like I said above, you could have a site that is NOT the default site and DOES list one or more IP addresses that it will answer to, but if it has no host header, then THAT site will respond to a request for THAT ip address and ANY host header.

So again, if you make sure to list host headers for all sites you have, then such host header attacks should not be possible. But of course it's a bit of work to make sure all is well. Most people just leave the "Default site" to "handle everything" and can't even reasonably name all the host names that it may be handling.

And if you have such a "default" site (with its bindings set for no host header and any ip address), and you don't really "need" it, you could take it out. Now IIS will ONLY respond to requests whose host headers match one of the listed site bindings. Just do be sure that you don't USE that default site for some purpose you're not considering.

One other thing: you can tell IIS to LOG the host header, so you can SEE what requests have been coming in asking for perhaps unexpected host names. It doesn't log the host header by default, but if you go to the logging feature in IIS and click "select fields", you will see toward the bottom "hosts" (or as its column will be labelled in the log file, cs-host, which means the client-to-server host requested). You may want to especially look at any default site you have (really any site whose binding has no host defined). You may be surprised to see what sort of odd hostnames come in,

I hope that explains things.

And you may wonder why you didn't find this explanation elsewhere. As I took a quick look at the top few results for host header attack, it was indeed sad to see that so many only discuss the problem and solutions in terms of Apache or Nginx, particularly the notion that a request having an unrecognized header would go to the "first" virtual host.

That's definitely not how IIS works--other in this general sense that for most people, the "first site" listed when they install IIS is the "default site", and it has (by default) these characteristics of the binding having no header and accepting ALL incoming IP addresses. But as I have shown above, this is also an issue for ANY site you have whose binding has NO host name defined.

I know that was a lot to take in, and I may have missed something or not explained it as well as I could. Let us know what you think.

And I should add that I agree with the concern and suggestion that James (Jamo) made. 🙂

We're using CF2016 & IIS10.  I haven't been able to manually perform a host header attack on our web applications.

Is there any reason that you haven't upgraded IIS to 8, 8.5 or 10?  (IIS 7.5 was released back on 10/22/2009.)

If your scan is PCI-related, it should automatically fail because the application is hosted using vendor-unsupported software. (Microsoft has announced Jan. 14, 2020, as the end-of-life date for Windows Server 2008 and 2008 R2.)

If you want to add a better layer of protection, consider using StackPath or CloudFlare.