HOST HEADER INJECTION

SPECIALIZATION TASK : 2

16CF
SHAIK MUHAMMAD USAMA
usamashaik41@[Link]
HTTP header :
 HTTP headers are components of the header sec on of request & response messages in the Hypertext
Transfer Protocol (HTTP), used to transfer data over the web.
 It helps browsers and servers understand how to handle the data.

Host header :
 The Host header is a specific HTTP header that tells the server which website (domain) the user wants
to access.
 The web server uses the value of this header to dispatch the request to the specified website or web
applica on.

Host Header Injection

 Host Header Injec on is an a ack in which an a acker can manipulate the Host header and cause the
applica on to behave in unexpected ways.
 Host Header Injec on is a web vulnerability that occurs when a web server trusts and uses the “Host”
header from an incoming “HTTP” request without valida ng it.
 An a acker can manipulate this header to trick the applica on into genera ng malicious links, redirec ng
users to untrusted domains, or even compromising user accounts (e.g., during password resets).
 It can lead to:
 Unauthorized Access to Sensitive Information
 Phishing attacks
 Password reset poisoning
 Session hijacking
 Web Cache poisoning
 Open redirect attacks

pg. 1
How Host Header Injec on Happens

 Host Header Injec on occurs when:

1. The applica on uses the Host header value to generate a link (such as a password reset URL).

2. The a acker sends a request with a fake Host header (e.g., Host: a [Link]).

3. The applica on includes the a acker's domain in the generated link or response.

4. The a acker can use that to steal tokens, trick users, or redirect them.

Signs of Host Header Injec on Vulnerability :

1. 🔗 Host Reflected in Links
o Your custom Host (e.g., a [Link]) appears in links in the response page.
2. Host Reflected in Emails
o Password reset or verifica on emails contain URLs using the a acker-supplied Host.
3. Redirec on to Malicious Domain
o The app redirects the user to the value set in the fake Host header.
4. Web Cache Poisoning
o The app caches content with the a acker-supplied host and serves it to others.
5. Error Messages or Crashes
o The app shows an error, crashes, or behaves unexpectedly when Host is changed.
6. Token Exposure in Host-based Links
o Reset tokens, session IDs, or other sensi ve data are included in URLs using the fake host.
7. Incorrect Applica on Logic
o The app loads the wrong site/content based on the injected host.
8. Reflected in Response Headers
o The Host or X-Forwarded-Host header is reflected in response headers or body.
pg. 2
 9. Bypassing Domain-based Access Controls
o The applica on grants access or loads unauthorized content based on the spoofed host.
10. Applica on Accepts Any Host
o No error or redirec on happens even when sending a random or a acker-controlled Host
header.

Tes ng Methodology :

1. Supply an Arbitrary Host Header

What it means:
 Modify the standard “Host” header in your request to use a malicious or fake domain, like:

Purpose:
 To see if the applica on reflects or uses this header in URLs, emails, redirects, or logic.

2. Inject Duplicate Host Headers

What it means:
 Add multiple “Host” headers in the same request:

Purpose:
 Some poorly configured servers may use the first or last host header, leading to inconsistent
or exploitable behaviour.

pg. 3
 3. Add Line Wrapping
What it means:
 Add unexpected line breaks or newline characters (e.g., %0d%0a) in the headers:

Purpose:
 To test how the server or proxy parses headers when forma ng is manipulated. This can lead
to bypassing filters or header smuggling.

4. Inject Host Override Headers

 These are alternate headers often used by reverse proxies or load balancers. Some
applications mistakenly trust these instead of the main “Host”.

Header Name Usage

X-Forwarded-Host: Often added by proxies to indicate the original Host
X-Host: Alternate Host indication (used in some platforms)
X-Forwarded-Server: Another proxy-related header
X-HTTP-Host-Override: Used to override Host values in certain proxy configs
Forwarded: Standardized header (Forwarded: host=[Link]) for modern proxies

Purpose:
 To test if the backend uses these headers when making decisions about redirection, token
generation, or domain rendering.

5. Supply an Absolute URL

What it means:
 Send a full URL in the request line or as a parameter:

Purpose:
 To check if the application parses or reflects absolute URLs, which may be exploited in open
redirect or token-leakage attacks.

pg. 4
 HTTP Host Header attacks
 Password reset poisoning
 Web cache poisoning
 Exploi ng classic server-side vulnerabili es
 Bypassing authen ca on
 Virtual host brute-forcing
 Rou ng-based SSRF
 Connec on state a acks

1. Password Reset Poisoning

 Password Reset Poisoning is a type of Host Header Injec on a ack where an a acker manipulates the
Host header in an HTTP request to poison password reset links, typically sent via email.
 This can allow a ackers to redirect vic ms to malicious websites or even hijack user accounts under
certain condi ons.

What Happens in Password Reset Poisoning?

When a user requests a password reset, most applica ons:
1. Generate a token for rese ng the password.
2. Embed that token into a password reset URL.
3. Send that URL to the user's email.
Here’s where the problem begins:
If the applica on uses the Host header from the incoming request to construct the full password reset link and
doesn’t validate or sani ze it, then a ackers can inject a fake host.
This process is simple enough and rela vely secure in comparison to some other approaches.

Impact of Password Reset Poisoning :

 Account takeover
 Phishing
 Token Leakage
 Trust damage
pg. 5
Prac cal Example :
Lab : Basic password reset poisoning
Task : This lab is vulnerable to password reset poisoning. The user carlos will carelessly click on any links in emails that
he receives. To solve the lab, log in to Carlos's account.
You can log in to your own account using the following creden als: wiener:peter. Any emails sent to this
account can be read via the email client on the exploit server.

Step 1 :
 Go to the login page and no ce the "Forgot your password?" func onality. Request a password reset
for your own account.

 A er submi ng username, you will get a password link to your mail

Step 2 :
 Go to the exploit server and open the email client.
 Observe that you have received an email containing a link to reset your password.
 No ce that the URL contains the query parameter temp-forgot-password-token.

Step 3 :
 Click the link and observe that you are prompted to enter a new password. Reset your password to
whatever you want.

pg. 6
Now, we logged into wiener account.

Step 4 :
 In Burp, study the HTTP history. No ce that the POST /forgot-password request is used to trigger the
password reset email. This contains the username whose password is being reset as a body parameter.
Send this request to Burp Repeater.

Step 5 :
 Back in Burp Repeater, change the Host header to your exploit server's domain name (OUR-EXPLOIT-
[Link]) and change the username parameter to carlos.
 Send the request.

Step 6 :
 Go to your exploit server and open the access log. You will see a request for GET /forgot-password with
the temp-forgot-password-token parameter containing Carlos's password reset token. Make a note of
this token.

pg. 7
Step 7 :
 Go to your email client and copy the genuine password reset URL from your first email. Visit this URL in
the browser, but replace your reset token with the one you obtained from the access log.

Step 8 :
 Paste this genuine password URL in new tab and change the token to Carlos password reset token that
we have retrieved and run the browser.
 Now, change Carlos's password to whatever you want, then log in as Carlos.

 This is how we perform HTTP Host Header A ack.

pg. 8
2. Web cache poisoning
 Web Cache Poisoning is an a ack where the a acker stores malicious or manipulated responses in the
cache, which are later served to innocent users.
 When combined with Host Header Injec on, the a acker forges the Host header so that the cache
stores a malicious or incorrect version of the response ed to that manipulated host.
 Fundamentally, web cache poisoning involves two phases. First, the a acker must work out how to
elicit a response from the back-end server that inadvertently contains some kind of dangerous payload.
Once successful, they need to make sure that their response is cached and subsequently served to the
intended vic ms.
Prac cal Example :
Lab : Web cache poisoning via ambiguous requests
Task : This lab is vulnerable to web cache poisoning due to discrepancies in how the cache and the back-end
applica on handle ambiguous requests. An unsuspec ng user regularly visits the site's home page. To solve
the lab, poison the cache so the home page executes alert([Link]) in the vic m's browser.

pg. 9
Step 1 :
 In Burp's browser, open the lab and click “Home” to refresh the home page.
 In Proxy > HTTP history, right-click the GET / request and select Send to Repeater.

Step 2 :
 In Repeater, study the lab's behaviour. No ce that the website validates the Host header. If you modify
the Host header, you can no longer access the home page.
 In the original response, no ce the verbose caching headers, which tell you when you get a cache hit
and how old the cached response is. Add an arbitrary query parameter to your requests to serve as a
cache buster, for example, “GET /?cb=glitch”. You can change this parameter each me you want a
fresh response from the back-end server.

 No ce that if you add a second Host header with an arbitrary value, this appears to be ignored when
valida ng and rou ng your request. Crucially, no ce that the arbitrary value of your second Host
header is reflected in an absolute URL used to import a script from /resources/js/[Link].
pg. 10
  Remove the second Host header and send the request again using the same cache buster. No ce that
you s ll receive the same cached response containing your injected value.

Step 3 :
 Go to the exploit server and create a file at /resources/js/[Link] containing the payload
alert([Link]). Store the exploit and copy the domain name for your exploit server.

Step 4 :
 Back in Burp Repeater, add a second Host header containing your exploit server domain name. The
request should look something like this:

pg. 11
Step 5 :
 Send the request a couple of mes un l you get a cache hit with your exploit server URL reflected in
the response. To simulate the vic m, request the page in the browser using the same cache buster in
the URL. Make sure that the alert() fires.
 In Burp Repeater, remove any cache busters and keep replaying the request un l you have re-poisoned
the cache. The lab is solved when the vic m visits the home page.

 This is how we perform Web Cache Poisoning via ambiguous requests.

pg. 12
3. Exploi ng classic server-side vulnerabili es
 Every HTTP header is a poten al vector for exploi ng classic server-side vulnerabili es, and the Host
header is no excep on. For example, you should try the usual SQL injec on probing techniques via the
Host header. If the value of the header is passed into a SQL statement, this could be exploitable.
 Exploi ng classic server-side vulnerabili es involves targe ng weaknesses in the server-side code,
configura on, or infrastructure that can allow a ackers to gain unauthorized access, manipulate data, or
execute malicious ac ons. Here’s a summary of common classic server-side vulnerabili es and how they
can be exploited:

1. SQL Injec on (SQLi) :

 Vulnerability : Occurs when user input is improperly sani zed before being used in SQL queries.
 Exploita on: A ackers can cra malicious SQL queries to manipulate databases, retrieve sensi ve
informa on, delete records, or execute administra ve ac ons.
 Example: ' OR 1=1 -- can bypass login authen ca on.
2. Command Injec on
 Vulnerability: Happens when user input is passed to system commands without proper valida on or
escaping.
 Exploita on: A ackers can execute arbitrary system commands on the server, leading to full control of
the machine.
 Example: ; rm -rf / could delete all files on the server if injected into a vulnerable form field.
3. Remote Code Execu on (RCE)
 Vulnerability: A flaw where an a acker can run arbitrary code on the server.
 Exploita on: A ackers can upload malicious scripts or inject code that the server executes, allowing
them to take full control of the server.
 Example: Uploading a PHP web shell through an insecure file upload feature.

Mi ga on:
 Input valida on and sani za on for all user inputs.
 Least privilege access control principles.
 Use parameterized queries to prevent SQL Injec on.
 Secure file uploads and avoid execu ng user-uploaded content.
 Session management with secure cookies and tokens.
 Regular security audits and vulnerability scans.

pg. 13
4. Bypassing Authen ca on
 Bypassing authen ca on via Host Header Injec on is an a ack where an a acker modifies the Host
header in an HTTP request to trick the server into gran ng unauthorized access, such as logging in as
an admin or accessing restricted areas.
Prac cal Example :
Lab : Host header authen ca on bypass
Task : This lab makes an assump on about the privilege level of the user based on the HTTP Host header.
To solve the lab, access the admin panel and delete the user carlos.

Step 1 :
 Send the GET / request that received a 200 response to Burp Repeater. No ce that you can change the
Host header to an arbitrary value and s ll successfully access the home page.

pg. 14
Step 2 :
 Browse to /[Link] and observe that there is an admin panel at /admin.

Step 3 :
 Try and browse to /admin. You do not have access, but no ce the error message, which reveals that
the panel can be accessed by local users.

Step 4 :
 Send the GET /admin request to Burp Repeater.

pg. 15
Step 5 :
 In Burp Repeater, change the Host header to localhost and send the request. Observe that you have
now successfully accessed the admin panel, which provides the op on to delete different users.

Step 6 :
 Change the request line to GET /admin/delete?username=carlos and send the request to delete carlos
to solve the lab.

 This is how we perform Host header authen ca on bypass.

pg. 16
5. Virtual Host Brute forcing

 Virtual host brute-forcing is a technique used to discover hidden websites or subdomains on a server
by sending mul ple requests with different Host headers to see which ones return valid responses.
What is a Virtual Host?
 A virtual host allows one server (one IP) to host mul ple websites/domains.
 Example: A server at [Link] may host:

 The a acker sends many HTTP requests, each with a different Host header, like:

 The goal is to find hidden subdomains or applica ons not meant to be public.
Why is it Dangerous?
 Can reveal:
o Hidden admin panels
o Internal dev/test environments
o Forgo en or misconfigured web apps
 These may be less secure or expose sensi ve data.
Mi ga ons
 Avoid exposing unnecessary virtual hosts.
 Use proper DNS and access controls.
 Monitor server logs for suspicious Host header scanning.

pg. 17
6. Rou ng Based SSRF (Server-Side Request Forgery) :
 Rou ng-Based SSRF is a type of Server-Side Request Forgery a ack that exploits how a server routes
internal network requests.
 The a acker manipulates the rou ng mechanisms (like DNS resolu on, IP encoding, or reverse proxies)
to force the server to access internal resources that are not directly exposed to the internet.
 Unlike tradi onal SSRF, where the a acker might directly use internal IPs like [Link] or 192.168.x.x,
but rou ng-based SSRF uses clever tricks to reach those internal endpoints indirectly, bypassing simple
filters and valida on logic.
How It Works:
Instead of directly calling an internal IP like h p://[Link], a ackers abuse rou ng logic to access internal
resources through:
 Internal hostnames (e.g., h p://internal-service/)

 Misconfigured reverse proxies

 Non-standard IP nota ons or encoding (like 2130706433 for [Link])
 DNS rebinding or resolvable internal DNS names
 Open redirectors that route the request internally

Prac cal Example :

Lab : Rou ng-based SSRF
Task : This lab is vulnerable to rou ng-based SSRF via the Host header. You can exploit this to access an insecure intranet
admin panel located on an internal IP address.
To solve the lab, access the internal admin panel located in the [Link]/24 range, then delete the user
carlos.

Step 1 :
 Send the GET / request that received a 200 response to Burp Repeater.

pg. 18
Step 2 :
 In Burp Repeater, select the Host header value, right-click and select Insert Collaborator payload to
replace it with a Collaborator domain name. Send the request.

pg. 19
Step 3 :
 Go to the Collaborator tab and click Poll now. You should see a couple of network interac ons in the
table, including an HTTP request. This confirms that you are able to make the website's middleware
issue requests to an arbitrary server.

Step 4 :
 Send the GET / request to Burp Intruder.
 Go to Intruder.
 Deselect Update Host header to match target.

Step 5 :
 Delete the value of the Host header and replace it with the following IP address, adding a payload
posi on to the final octet :

pg. 20
Step 6 :
 In the Payloads side panel, select the payload type Numbers. Under Payload configura on, enter the
following values:

Step 7 :
 Click “Start a ack”. A warning will inform you that the Host header does not match the specified target
host. As we've done this deliberately, you can ignore this message.

Step 8 :
 When the a ack finishes, click the Status column to sort the results. No ce that a single request
received a 302 response redirec ng you to /admin. Send this request to Burp Repeater.

pg. 21
Step 9 :
 In Burp Repeater, change the request line to GET /admin and send the request. In the response,
observe that you have successfully accessed the admin panel.

Step 10 :
 Study the form for dele ng users. No ce that it will generate a POST request to /admin/delete with
both a CSRF token and username parameter. You need to manually cra an equivalent request to
delete carlos.

Step 11 :
 Change the path in your request to /admin/delete. Copy the CSRF token from the displayed response
and add it as a query parameter to your request. Also add a username parameter containing carlos.
The request line should now look like this but with a different CSRF token :
 GET /admin/delete?csrf=___________________&username=carlos
 If session cookie is not already present in request then, copy the session cookie from the Set-Cookie
header in the displayed response and add it to your request.

pg. 22
Step 12 :
 Send the request to delete carlos and solve the lab.

 This is how we perform Rou ng-based SSRF a ack.

__________________________________________________________________________________________

7. Connec on State A acks :

 A connec on state a ack is a type of a ack where the a acker opens many incomplete or long-las ng
connec ons to a server or firewall, using up its memory and resources, eventually making it unable to
handle new or real user connec ons.
 the a acker inten onally keeps a network or applica on connec on in an incomplete or half-open
state, consuming the server's resources.

Host Valida on Bypass via Connec on State A ack :

 Host valida on is a security measure where the server checks the Host header (or the target of the
request) to ensure requests are only made to allowed domains or IPs. It is commonly used to prevent
SSRF, open redirect, or unauthorized internal access.
 However, when combined with a connec on state a ack, this valida on can be bypassed, especially if
the logic responsible for valida on and the logic responsible for rou ng the request are not perfectly
synchronized, which happens in many reverse proxies, applica on firewalls, and load balancers.
 Host valida on bypass via connec on state a ack is a technique where an a acker sends slow or
incomplete requests to confuse the server, causing it to skip or fail to properly check the Host header.
This allows the a acker to access internal or restricted systems by bypassing host-based security
checks.

pg. 23
Prac cal Example :
Lab : Host valida on bypass via connec on state a ack
Task : This lab is vulnerable to rou ng-based SSRF via the Host header. Although the front-end server may
ini ally appear to perform robust valida on of the Host header, it makes assump ons about all requests on a
connec on based on the first request it receives.
To solve the lab, exploit this behaviour to access an internal admin panel located at “[Link]/admin”, then
delete the user “carlos”.

Step 1 :
 Send the GET / request to Burp Repeater.
 Make the following adjustments :
Change the path to /admin.
Change Host header to [Link].
 Send the request. Observe that you are simply redirected to the homepage.

pg. 24
Step 2 :
 Duplicate the tab, then add both tabs to a new group.
 Select the first tab and make the following adjustments :
Change the path back to “/”.
Change the Host header back to “[Link]”.
 Using the drop-down menu next to the Send bu on, change the send mode to Send group in sequence
(single connec on).

Step 3 :
 Change the Connec on header to keep-alive.

 Send the sequence and check the responses. Observe that the second request has successfully
accessed the admin panel.

Step 4 :
 Study the response and observe that the admin panel contains an HTML form for dele ng a given user.
Make a note of the following details:
The ac on a ribute (/admin/delete)
The name of the input (username)
The “csrf” token.

pg. 25
Step 5 :
 On the second tab in your group, use these details to replicate the request that would be issued when
submi ng the form. The result should look something like this :

Step 6 :
 Send the requests in sequence down a single connec on to solve the lab.

 This is how we perform Host valida on bypass via connec on state a ack.
pg. 26
References :
 Password reset poisoning :
h ps://[Link]/web-security/host-header/exploi ng/password-reset-poisoning/lab-host-
header-basic-password-reset-poisoning

 Web cache poisoning :

h ps://[Link]/web-security/host-header/exploi ng/lab-host-header-web-cache-poisoning-
via-ambiguous-requests

 Bypassing authen ca on :
h ps://[Link]/web-security/host-header/exploi ng/lab-host-header-authen ca on-bypass

 Rou ng-based SSRF :

h ps://[Link]/web-security/host-header/exploi ng/lab-host-header-rou ng-based-ssrf

 Connec on state a acks :

h ps://[Link]/web-security/host-header/exploi ng/lab-host-header-host-valida on-bypass-
via-connec on-state-a ack

pg. 27