Automated Detection of Host Header Attacks

Automated scanning for certain classes of vulnerabilities is now possible with AcuMonitor, a service available for Acunetix Web Vulnerability Scanner version 9. One of these new classes of vulnerabilities is Host Header attacks.

To display the contents of a website, the browser first resolves the website domain ( to an IP address, connects to this IP address and then makes a request like the one listed below:

GET / HTTP/1.1
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.95 Safari/537.36

Very often multiple websites are hosted on the same IP address. This is where the Host Header comes in. This header specifies which website should process the HTTP request. The web server uses the value of this header to dispatch the request to the specified website.  Each website hosted on the same IP address is called a virtual host.

But what happens if we specify an invalid Host Header? If Apache receives an unrecognized Host Header, it passes it to the first virtual host defined in httpd.conf. Therefore, it’s possible to send requests with arbitrary Host Headers to the first virtual host. [link]

Another way to pass arbitrary Host headers is to use the X-Forwarded-Host Header. In some configurations this header will rewrite the value of the Host header. Therefore it’s possible to make a request like:

GET / HTTP/1.1
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.95 Safari/537.36

In this case the web application handling will receive this HTTP request but the value of the Host header will be

Host Header attacks where first presented by blogger James Kettle in the post “Practical HTTP Host Header attacks”. [link] The blog post contains more tips and tricks on exploiting and securing websites against this type of attack.

Web applications don’t usually expect to receive an invalid value for the Host header. Various web applications handle this situation differently:

Some applications trust this value enough to write it to the page without HTML-encoding like
<link href=”http://_SERVER[‘HOST’]”    (Joomla)

Others append secret keys and tokens to links containing it
<a href=”http://_SERVER[‘HOST’]?token=topsecret”>  (Django, Gallery, others)

And some even directly import scripts from it:
<script src=”http://_SERVER[‘HOST’]/misc/jquery.js?v=1.4.4″>  (Various)

There are two ways to exploit this class of problems:

  1. Web-cache poisoning; manipulating caching systems into storing a page generated with a malicious Host and serving it to others.
  2. Abuse alternative channels like password reset emails where the poisoned content is delivered directly to the target.

Acunetix WVS v9 can detect Host Header Attacks

Some cases (where the Host Header is directly reflected on the response) are relatively easy to detect. Here is a screenshot from the Host Header attack alert generated for one of our test websites ( vulnerable to this type of attack.

Simple Host Header Attack -Acunetix

Click to enlarge


Other cases however, are much harder to detect.

Password reset poisoning

A common way to implement the password reset/forgotten password functionality is to generate a secret token and send an email with a link containing this token. However, what happens if you request a password reset with an attacker controlled Host Header?

If the web application doesn’t protect against this type of attack, it will use the attacker-controlled Host value when composing the reset link. When the user receives this email, and clicks on the reset link, the password reset link containing the token will be sent to the attacker.

As an example, we will use an older version of Piwik that was vulnerable to this type of attacks. When this application is scanned, Acunetix WVS will locate the password reset page and inject a custom Host header pointing to the AcuMonitor domain. Piwik will generate the password reset link using this value and send an email like:

Piwik will generate the password reset link using this value and send an email like

Click to enlarge

As you can see, the password reset link points to a different domain (the original scanned URL was http://bld02/piwik-0.4.5/ and the password link should normally point to the bld02 domain).

If the user clicks on this link, AcuMonitor will capture this request and send an email with a Host Header Attack alert containing the full URL.

Host Header Attacks Alert Details, AcuMonitor by Acunetix WVS

Click to enlarge

Share this post
  • “Host header was reflected inside a A tag (href attribute).” the scan says.. I’ve got an IIS 8.5 site with the correct host header binding. Also scanned all the code for any HOST or SERVER_NAME use..

    Could this be a false positive? It might be helpfull if the reported stated which href tag had the evil host name.

  • Hi,

    The scan results should include the HTTP request and the HTTP response. This will allow you to investigate the further the vulnerability detected. in the HTTP response, search for the domain listed in the vulnerability.

  • Hi Dear

    Can you give us one example pls which is how you exploited the attack to send email i mean when we change reflected link like we need to replace the webpage yes but what we need to have in i mean you meant to send password reset code with email than i need to use same script like piwik isn’t it in the ? You gave screen shoots the password reset link received but did not show how you make it send can you please give more detailed information about this attack i need for my tests often..

  • Leave a Reply

    Your email address will not be published.