1

I am trying to correct a host header vulnerability from the server side as much as possible. The vulnerability is an HTTP host header attack. What I would like to do is only allow valid host headers to be passed through running applications. This way a host header that should be example.com doesn't get passed down as evil.com. There is a decent explanation of this vulnerability here: http://www.skeletonscribe.net/2013/05/practical-http-host-header-attacks.html.

I think URL Rewrite could assist with this, but I don't have a lot of experience with it so I am not sure. Has anyone hardened up their servers against this attack?

The server is setup with header bindings for allowed domains, though this will not stop a request containing a different host header value.

If I do figure out a way to filter, detect that the host header is incorrect, what type of response should be returned?

Improve this question
2
  • Not an answer since you want to use IIS, but what about putting a reverse-proxy like nginx in front of the HTTP server? Have it stop all invalid hostnames from ever hitting the HTTP server.
    – amccormack
    Jun 5, 2015 at 16:24
  • Oh, that does give me a different thought though! We have and F5 in front of the servers, they would be able to do the same thing.
    – Brettski
    Jun 5, 2015 at 16:52

3 Answers 3

Reset to default
1

In short, don't use wildcard bindings.

Only bind applicable host names to websites and be specific. For example, only allowing www.website.com will only allow requests with that host header value. Any others will not get processed by the website so you're essentially white-listing the acceptable host names.

By taking the URL Rewrite (or similar) approach, a new rule needs to be added for each "bad" request. This is not a good support model (i.e. whack-a-mole) for there is no way to keep up with the possible combinations. As an example, I could register mysite.foo to your IP and now you need to add a rule. By taking the recommended approach and not using wildcard bindings the request won't even go to IIS for there isn't a website configured to process the request.

The vulnerability mentioned is from websites being configured to accept any host name. In doing so it allows that value to populate the variable which is no longer trustworthy as it could be anything. By taking the approach of only binding specific host names you're ensuring that only those values will populate the variable and are therefore trustworthy.

Improve this answer
5
  • The binding doesn't really matter as the host header value can be changed to a different value. I have explicit bindings on my server and the exploit still exists. A host value of a different value is still passed through.
    – Brettski
    Jun 11, 2015 at 18:09
  • @Brettski sounds like you have a wildcard binding. The following URL describes valid bindings. As long as those are explicitly set you won't have the issue described. blogs.technet.com/b/chrad/archive/2010/01/24/…
    – user2320464
    Jun 11, 2015 at 23:00
  • I can guarantee I am not using wildcard binding. I would show you though sharing such information is restricted by InfoSec. As our first fix attempt to this issue we set explicit bindings for the websites. Using Burp the tester was able to update the Host value before sending the request to our server and the code read the HTTP_HOST value as this new value.
    – Brettski
    Jun 12, 2015 at 19:22
  • A website will only respond to requests as specified in the bindings. If you've found a way around this then you should consider technet.microsoft.com/en-us/security/ff852094.aspx
    – user2320464
    Jun 12, 2015 at 19:57
  • I don't think you are understanding the nature of the exploit. The request is still coming through on the bound domain. The host header submitted with the request is being changed. The server doesn't not care what this value is.
    – Brettski
    Jun 12, 2015 at 20:19
0

To answer your original question, yes URL Rewrite can accomplish this with IIS. URL Rewrite essentially just creates entries in the web.config file at /wwwroot/web.config (or creates it if it doesn't already exist).

The web.config can be manually manipulated to add the host injection rules, but IIS won't know how to read the web.config unless URL Rewrite is installed. The website will fail to start. So URL Rewrite must be installed even if you want to use a script or manual process to update your server(s).

The below rules says for the HTTP_HOST header if it's not "10.141.13.170" and it's not "253.23.65.155" and it's not "website.com", then abort the request. The multiple entries allow you to accommodate an internal IP, and external IP and a domain name, for example.

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
  <system.webServer>
    <rewrite>
      <rules>
        <rule name="Host_Injection_Prevention_Rule_1" enabled="true" patternSyntax="Wildcard" stopProcessing="true">
          <match url="*" />
          <conditions>
            <add input="{HTTP_HOST}" pattern="10.141.13.170" negate="true" />
            <add input="{HTTP_HOST}" pattern="253.23.65.155" negate="true" />
            <add input="{HTTP_HOST}" pattern="website.com" negate="true" />
          </conditions>
          <action type="AbortRequest" />
        </rule>
      </rules>
    </rewrite>
  </system.webServer>
</configuration>
Improve this answer
4
  • I assume this could go into the applicationHost.config as well to apply to all sites.
    – Brettski
    Jun 5, 2015 at 19:38
  • Yes, it could, but you would have to list all of the IPs and domains for all of your sites in one list. The only concern there would be that each of your sites would accept the HTTP_HOST for any other site. So if you have A.com, B.com and C.com, they would each accept each others HTTP_HOST header. That may not be a practical security issue, but it could cause an audit failure, if that's your concern.
    – md_1976
    Jun 6, 2015 at 2:06
  • Only two domains served, so not an issue. What type of HTTP result is given with <action type="AbortRequest" /> ?
    – Brettski
    Jun 11, 2015 at 18:11
  • The abort request action causes the URL Rewrite module to drop the HTTP connection for the current request. technet.microsoft.com/en-us/library/ee215207(v=ws.10).aspx
    – user2320464
    Jun 12, 2015 at 5:50
0

Your question is from 2015, but in 2018 Microsoft released an security advisory [0][1] stating the very problem you suspected back than. To quote from the advisory:

For example, if IIS is configured to respond to requests for contoso.com or *.contoso.com hosts, the application is protected.

If IIS is configured to respond to any request from any host, the application is vulnerable.

[...]

Affected Software

Any ASP.NET Core hosted application which is directly exposed to the internet, or hosted behind a proxy which does not validate or restict host headers to known good values.

Improve this answer

You must log in to answer this question.

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