In simple words, Host header injection is to change the value of Host
header in the request to any other domain. Then the server uses the
modified Host value in common tasks like redirection links, sending emails,
password reset links, etc., which can lead to a variety of attacks. Another
possible injection technique for Host headers can be through
X-Forwarded-Host header. In some configurations, this header might rewrite
the value of Host header.
In many cases, developers are trusting the HTTP Host header value and using
it to generate links, import scripts and even generate password resets
links with its value. This is a very bad idea, because the HTTP Host header
can be controlled by an attacker. This can be exploited using web-cache
poisoning and by abusing alternative channels like password reset emails.
And this could be exploited in mainly 3 ways (mainly, but that's open to
- Cache Poisoning :- If your application feeds the page with a domain
taken from the request (when rebuilding absolute URLs in HTML links) then
there's maybe a chance that these bad domains end in the cached version of
the page for /uri. Quite hard to perform (the cache may end up caching the
page as http://www.openbsd.org/uri and not /uri.
- Bad links in email :- Say your application is sending a password reset
one-time link, with the URL taken from the host header, then the attacker
could hope that someone will click the link with evil.com domain. But it
means someone clicking on a reset password email link without asking for a
password reset (as the attacker performed the bad query)
- CRLF Injection :- As with all injected headers, one goal could be to
get a response where a very bad host entry (containing CRLF, or %0a%D,
that's "\r\n") would be reused without filtering on the response headers.
Leading to headers injection in the response
The web application should use the SERVER_NAME instead of the Host header.
It should also create a dummy vhost that catches all requests with
unrecognized Host headers. This can also be done under Nginx by specifying
a non-wildcard SERVER_NAME, and under Apache by using a non-wildcard
serverName and turning the UseCanonicalName directive on. Consult
references for detailed information.
On Mon, Aug 05, 2019 at 08:59:46AM -0400, Daniel Jakots wrote:
> On Mon, 5 Aug 2019 05:38:46 -0700, Claus Assmann
> <[hidden email]> wrote:
> > On Mon, Aug 05, 2019, Marc Espie wrote:
> > > [[...]] the same useless mp4 video.
> > Maybe it is/contains an (attempt of an) exploit?
> Unlikely since their signature says "Certified Ethical Hacker"
The problem with security is that there are more wannabe attackers