Is IIS and ASP vulnerable to the same Host Header Attacks we have seen on Apache and Nginx? Specifically the attacks that use the HTTP Host Header to reset a password or implement web-cache poisoning. These specific attacks use the SERVER and HOST variables.

Any insight or help is greatly appreciated.


2 Answers 2


I agree with Kotzu, I would have commented, but just for being able to post a screenshot, I am posting this as answer.

Short Answer:
Yes, Host Header Attacks are possible on IIS and ASP.NET stack.

Password Reset Poisoning:
This happens if code is written poorly, on website when user requests a link to reset password, the website sends out a link with secret token to that user's email address.

Say that link is http(s)://[genuinesite]/resetpassword.aspx?someguid And guid would be a key to a record in database which knows for whom to reset the password.

But if code was written poorly to create that link, it would use Protocol + Host Header + "/resetpassword.aspx?" + guid,
then attacker can easily pass host header to his own website, So the genuinesite will generate and send email with link like http(s)://[jenuinesite]/resetpassword.aspx?someguid
and the attacker would have that site there, and he would be able to get the query string parameters and be able to reset password on behalf of the user, provided that the user actually clicks the link from email. And usually they do because email is really sent by genuinesite.

Many popular software components have this vulnerability.

Cache poisoning:
Cache can be poisoned by HTTP Response Splinting too which is again not common now a days, but here we are talking about Host Header. Caches are now a days host-aware, so with Host Header if someone tries to poisons the cache, it will be kept separate from the genuinesite's cache.

Basically, while generating (rendering) html, in the code if at any place there is poor code where it generates html/javascript based on HOST then it could be vulnerable. Provided there is some kind of server side or proxy caching of the rendered html.

Say the code is generating html like Home then by manipulating host header you can make it like Home

And that page would be cached server side, and the attacker can steal cookies of all the users whom that cached page gets served.

Obviously, the attacker will use Pragma: no-cache to remove the genuinely cached page first and then position the cache with host header manipulated version.

But like I said, in ASP.NET and IIS world I haven't seen Cache Poisoning with Host Header much, but we never know people write poor code all the time.

How do we prevent this:
I think the easiest way (and one of the best practice) is to have proper binding settings in your IIS, even if you are hosting only one website with your IIS.

You can even have multiple allowed host names for one web site.

IIS Website Binding

This way, if someone changes the host header, it will not even reach your web site in IIS.

  • This is not true on IIS 10 and likely other versions. If you have a request: GET /JSLib/ThirdParty/jquery-ui-1.13.2/jquery-ui.min.js HTTP/1.1 Host: evilhosttOVOG3gY.com X-Forwarded-Host: contoso.com Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8 IIS will process and reflect the result as : HTTP/1.1 301 Moved Permanently Content-Type: text/html; charset=UTF-8 Location: evilhosttOVOG3gY.com/JSLib/ThirdParty/jquery-ui-1.13.2/…
    – MikeJ
    Nov 11, 2022 at 15:43

The "HOST" header is part of the http protocol, vulnerable applications are vulnerable because they insert the value of this header into the application code without proper validation, this means not only applications hosted on Apache/Nginx can be vulnerable. In short, the answer is yes, your application could be vulnerable no matter what kind of language/server you use. Avoid pulling information out of this header, since manipulating it from the client side is trivial.

  • Are there steps to Mitigate these kinds of Risks specifically for IIS and ASP or Javascript? Is this a configuration issue?
    – Brian
    Apr 1, 2014 at 23:41
  • As I mentioned, the vulnerability occurs when the code inserts the header value in the code, for example a developer might create a link on the webpage like this: http://[[HOST_HEADER]]/mylink.asp (since a non-tempered host header contains your own host), if an atatcker modifies it however, your link will end up pointing somewhere else. Depending on the language you use, ASP,C#,VB there are many ways to obtain header values, as such my recommendation would be to make sure you are not directly pullling header values in your code and then using them someplace else without validation.
    – Kotzu
    Apr 1, 2014 at 23:56
  • You might want to avoid using them at all, but if its absolutly necessary, you need to implement a whitelist validation of the header before using it. Here is a link with some info, its PHP oriented but it will help you understand what I´m trying to say: skeletonscribe.net/2013/05/…
    – Kotzu
    Apr 1, 2014 at 23:59
  • Do you know anything about setting up an IIS Configuration that uses Explicit host headers?
    – Brian
    Apr 2, 2014 at 16:05
  • Never heard of that before, do you mean defining the host header in the web server? If so, there is no way to do that, since the HOST header comes in the http request (from client to server) meaning the client sets it up, not the server.
    – Kotzu
    Apr 2, 2014 at 16:39

You must log in to answer this question.

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