Identifying, Exploiting, and Preventing Host Header Attacks on Web Servers

Summary

A typical web application uses HyperText Transfer Protocol (HTTP) for communication purposes. There are various attributes in HTTP, termed as Headers (for both Request and Response), that have their significance, and all the attributes in HTTP Headers should be configured securely for communication purposes. Often most of the attributes in HTTP Headers are misconfigured in web servers which makes the entire HTTP communication vulnerable to various cyber-attacks. 

HTTP Host headers are among one of the HTTP Header attributes that are misconfigured often and it can cause potential threat which is termed as Host Header Injection. In this literature, the author has shown how to exploit HTTP Host Header, where web servers are misconfigured in such a way that web servers respond to malicious HTTP requests without identifying the origin from which HTTP(S) Request(s) (Host Header) is made. In this literature, the author has also shown how to check incoming traffic on web servers w.r.t the origin or HTTP Host Headers and rejecting the same in case request is not coming from whitelisted origin.

Keywords: Host Header Injection Attack, HTTP Request Header, and HTTP Response Header, X-Forwarded-Host Header, Preventing Host Header Injection

Introduction

In this section, the author has explained the background concepts, like HTTP Basics[1], HTTP Versions, HTTP Status Codes, HTTP Methods, HTTP Headers that should be understood properly for understanding Host Header Injection Attack, from the scratch. All web application uses HTTP for communication. HTTP stands for HyperText Transfer Protocol which is based on Client-Server Architecture. The HTTP protocol is generally used for accessing resources over the internet. Figure 1. shows the typical Client-Server Architecture where a Client request some resources from the server, and the server processes the request and serves the Client in form of Response.

Figure 1. Client-Server Architecture

HTTP Versions

There are basically three versions of HTTP Protocol, HTTP 1.0, HTTP 1.1, and HTTP 2. 

HTTP version 1.0: Marked as HTTP/1. It is the old version, may be treated as outdated. In this framework for each resource, a new request to the server is made over the World Wide Web and later the connection is kept close. 

HTTP version 1.1: Marked as HTTP/1.1. Most of the web applications that are running today use HTTP version 1.1 for communication. It uses a single connection to request resources from the server over World Wide Web, multiple times. 

HTTP version 2:  Marked as HTTP/2[2]. This version of HTTP was developed by Google, which is the major revision of HTTP protocol over the World Wide Web. There are a couple of major issues in HTTP version 1.1, like Head of line blocking, meaning when a client is making multiple requests it get server on a Synchronous basis, or first come first server basis, the request made later in the queue have to wait till the prior request made get the response from the server. 

Since HTTP is a stateless protocol for identifying the request, certain headers need to be sent to the server, this gives rise to redundancy in the Request Header, which is being transmitted again and again, and all these major issues are addressed in HTTP 2. In HTTP 2 Single TCP connection itself services multiple HTTP Requests by Multiplexing. HTTP 2 uses the HPACK compression technique to compress the HTTP Headers, using which the HTTP Headers are being shared among the Requests. Most of the browsers nowadays support HTTP 2, slowly and steadily HTTP 2 will become the mainstream protocol in coming years for communication over the World Wide Web.

HTTP Status Codes

When browsers send requests to Server, the server responds with HTTP Status Codes[3] that are 3 digits long, which have a certain meaning. 

1xx: Code starting with 1 provides some information while the connection is still in progress. 

100 - continue, 101- switching, 103 - checkpoint

2xx: Code starting with 2 means a successful connection was made. 

200 - OK, 201- Created, 202- Accepted, 203- Non-Authoritative Information, 204- No Content. 

3xx- Code starting with 3 indicates redirection like 301 - Moved Permanently, 302 - Found

4xx- Code starting with 4 indicates there was some client-side error, like 400- Bad Request, 401- Unauthorized [Client is not authorized to perform the c/o action], 403- Forbidden [Client has no rights to access the resources], 404 - Not Found [The resource client is looking for in the server is not present]. 

5xx- Code starting with 5 indicates there is a server-side error. 500- Internal Server Error, 502- Bad Gateway, 503- Service Unavailable, 504- Gateway Timeout, 505- HTTP Version not supported. 

HTTP Methods: HTTP Methods[4] are a type of request that clients want to send. Below are HTTP Methods that are commonly used. 

GET- Fetching out information from the server. 

HEAD- Fetching out information regarding resource header. 

POST- Send data to the server for processing. 

PUT- Deposit data on server, the inverse of GET, it is marked as an unsafe method as per security guidelines. 

OPTIONS- It is used for identifying or fetching out information about which HTTP Methods does the server supports. 

DELETE- This method is used for removing a resource or data from the server, this method is also marked as unsafe methods as per security guidelines.

What Is HTTP Header?

HTTP headers[5] let the client and the server pass additional information with an HTTP request or response. An HTTP header is defined by a case insensitive name followed by a colon(:) followed by its value example, Host: www.test.com

Headers can be grouped into four types according to their context, which is defined as follows: 

1. General Headers: Holds additional information about HTTP Request and Response, but it has nothing to do with the content itself. 

2. Request Headers: Holds additional information about HTTP Request and it doesn’t relate to the content of the message. 

3. Response Headers: Holds additional information about HTTP Response, and it also doesn’t relate to the content of the message. 

4. Entity Headers: These are used in HTTP Request or Response to describe the content of the message. 

Figure 2 shows the representations of Format Request and Response message format. The only difference lies in the first field i.e in Format of Request message the first field is Request Line whereas in Format of Response message the first field is Response line.

Figure 2. HTTP REQUEST and RESPONSE Message format.

There are various HTTP Headers which has their significance in this literature author will only discuss HTTP Host Headers and HTTP X-Forwarded-Host Headers as both these HTTP Headers are widely used for exploiting Host Header Injection Vulnerability.

What Is a HOST Header?

The HTTP Host request header[6] is the mandatory header (as per HTTP/1.1 and HTTP/1.2 protocol version) that specifies the host and port number of the server to which the request is being sent.

If no port is included, the default port for the service requested is implied, 443 for an HTTPS URL, and 80 for an HTTP URL.

Example: Host: www.mysite.net

What Is X-Forwarded-Host?

Syntax: X-Forwarded-Host: www.site.com 

X-Forwarded-Host header[7] is used to identify the original request initiated by the client. Since hostnames and ports differ in reverse proxies, this header is used to identify the original request. This header is also used for debugging purposes.

What Is a Host Header Attack?

As per HTTP 1.1 and HTTP 1.2 protocol version, HTTP Host Headers are mandatory to be embedded into HTTP Request, to identify the origin from which request is initiated, or which resource the client is trying to access. Since in modern days computing we have a load balancer, virtual hosting that uses the same IP for hosting multiple websites, thus it is essential to identify which resource the client wants to access. 

Sometimes, the HTTP host headers are not properly validated on the web servers before processing or serving the requests which give scopes to the attacker to exploit this practice by sending a fake header that contains a domain name that, for example, can be used to corrupt the web cache or password reset emails. In a security context, this type of attack is known as a Host Header Injection attack. Host Header Injection vulnerability is a medium severity vulnerability having a Base score of 5.4 [CVSS version 3.X] and is identified under CVE-2020-11814 [9]. 

Identifying and Exploiting Web Applications That Are Vulnerable to Host Header Injection Attack

 Arbitrary Host Header Injection: Here the author will pass an arbitrary HTTP Host Header value, which will be different from the actual HTTP Host Header. If the server responds with a 200 HTTP status code, it means there is a misconfiguration on the webserver as it is not validating the origin from where a request is coming. The author has hosted a simple HTML page on the application on Nginx and apache2 web server applications running on ports 4000 and 80 respectively, IP address of the system is 10.55.18.21. Figure 3 and Figure 4. show Default page loading on the web browser, and GET Response from the web server, where the web page is hosted on the Nginx web server.

Figure 3. Response From Nginx Web Server

Figure 4. Response from Apache Web Server

Passing arbitrary Host Header on the HTTP Request, on both the web servers. 

Nginx  

Figure 5. Arbitrary Host Header Injection on Nginx Web Server

Apache2

Figure 6. Arbitrary Host Header Injection on Apache2 Web Server

Both the web browsers are responding to the request which is coming has a different origin. Figure 5. and 6 illustrates the same. This attack is treated as an arbitrary host header injection which can be exploited further. Also, most of the web servers that are hosted without the help of Cloud technology don’t validate the origin of the request from where it is coming, and hence give scope for Arbitrary Host Header Injection.

Reflected Host Header Injection

Here the author has illustrated defacing the website by exploiting Host Header Injection. The author has created a vulnerable Demo application on Nginx web server, Vulnerable Application Instance URL: http://10.55.18.21:4200 [Host Header Injection Vulnerable App Running on Nginx Web Server]. 

Also for illustrating Host Header Injection that can lead to web cache poisoning author have hosted an application running on http://172.16.10.47:8080

Attack Scenario: Figure 7, shows the attack scenario in vulnerable web servers. Once the client requested accessing the web application, the same request would be intercepted by Attacker and the further attacker would change the HTTP Host Header to evil.com, which in return would cause rendering of http://www.evil.com web page to the client. This can be a serious issue, in case HTTP Host Headers are not validated before processing requests, just think of the conditions where users are resetting passwords, this issues thus can be escalated further to account take over and web cache poisoning [Web cache poisoning is explained in a later section]. Please Note: For performing this attack to the highest level, intercepting HTTP requests would be needed.

Figure 7. Performing Host Header Attack

Here the author has configured Man In The Middle (MITM) set up on the local system, tool used was Burpsuite Community Edition v2021.10.13, which had an Embedded Browser configured with it [Default Proxy on the embedded browser was setup on 127.0.0.1:8080], and Proxy Service was running on Port 8080. Below steps were performed by the author for exploiting Host Header Injection Vulnerability. 

Step 1: From the browser (embedded browser) client will request for accessing the Website: http://10.55.18.21:4200 

Step 2: The request will first get routed from http://127.0.0.1:8080 [Burpsuite Proxy], Intercept was kept on by default. A snapshot of intercepted request is shown in Figure 8.

Figure 8. Intercepted Request

Step 3: Change the Host Header from 10.55.18.21:4200 to www.evil.com. Figure 9. illustrates the same.

Figure 9. Changing Host Header of the Intercepted Request 

Step 4: Forward the request and the default page: http://www.evil.com/ was loaded on the browser. Figure 10, 11, and 12 shows the illustration of the same.

Figure 10. Evidence of Reflected Host Header Injection

Figure 11. Web page being redirected to http://www.evil.com 

Figure 12. Complete Redirection

Illustrating Web Cache Poisoning

Step 1: Send the “/” request which was loaded after accessing the URL http://172.16.10.47:8080 to the Repeater Section of Burpsuite, click on the Send button to get the response from the server. Figure 13 illustrates the same.

Figure 13. Intercepting request of http://172.16.10.47:8080 at / 

Step 2: Now change the Host Header from 172.16.10.47:8080 to www.evil.com and click on the Send Button to obtain the c/o response from the server. Figure 14. shows the response.

Figure 14: Evidence of Web Cache Poisoning through Host Header Injection

From figure 14, it can be shown that on 5 of the HTML tags, http://www.evil.com/ was loaded which makes the web application running on http://172.16.10.47:8080 vulnerable to Web Cache Poisoning. It can be escalated to critical issues, like Cross-Site Scripting. Similarly, the X-Forwarded-Host header can be manipulated or tampered with to achieve the above discussed Security exploits. Thus Host Header Injection attack can cause severe issues. Thus it has become essential to prevent Host Header Injection by validating HTTP X-Forwarded-Host and HTTP Host header.

Mitigating Host Header Injection Vulnerability: Figure 15 shows the flowchart diagram on how to prevent the Host Header Injection.

Figure 15. Flow chart diagram in mitigating Host Header Injection Attack

Web servers must be configured with a way through which it should be able to identify the HTTP Host and X-Forwarded-Host Headers and serve the response to the client accordingly. Like in case host and x-forwarded-host headers are not whitelisted or not identified web server should respond with 403 Forbidden status code. The author in this section has shown a way to mitigate host header injection on Nginx and Apache2 web servers (Two of the most commonly used web servers for web application hosting) by validating the origin of HTTP Request w.r.t Host Headers and X-Forwarded-Host Headers, and have configured 403 Forbidden HTTP Status code in case request is coming from an unidentified origin.

Configuration on Nginx Web Server:

The author has modified the configuration file /etc/nginx/sites-enables/default, and appended below checks to validate the origin of HTTP Request.  

if ( $host !~* ^(127.0.0.1:4000||localhost:4000||10.55.18.21:4000)$ ) {

       return 403;

  }

 if ($http_x_forwarded_host !~* ^(127.0.0.1:4000||localhost:4000||10.55.18.21:4000)$) {

        return 403;

  }

Figure 16 shows the snapshot of the Nginx web server's configuration file, and Figure 17 shows the web server throwing HTTP “403” status code [Forbidden] when the request is getting originated from a different domain, [in short when HTTP Host Headers are being tampered].

Figure 16. Nginx Configuration to prevent Host Header Attack

Figure 17: Nginx Web Server Throwing 403 on Host Header Attack 

Configuration on Apache2 Web Server: 

The author has modified the configuration file /etc/apache2/sites-enabled/000-default.conf, and appended below checks to validate the origin of HTTP Request:

<If "req('Host') != '10.55.18.21'">

      Deny from all

</If>

<If "req('HTTP_X_FORWARDED_HOST') != '10.55.18.21'">

      Deny from all

</If>

Figure 18 shows the snapshot of the Apache2 webserver’s configuration file, and Figure 19 shows the web server throwing HTTP “403” status code [Forbidden] when the request is getting originated from a different domain, [in short when HTTP Host Headers are being tampered].

Figure 18. Apache2 Configuration to prevent Host Header Attack

Figure 19. Apache2 throwing 403 Status code on Host Header Attack

Conclusion

Host Header Injection attack is one of the most common attacks, which can be escalated to some serious attacks like Account takeover, Website defacing, Cross-Site Scripting, and others. The author in this section has shown how to identify web servers that are vulnerable to Host Header Injection and how to exploit Host Header Injection. The author has also shown how to prevent Host Header Injection by validating the request w.r.t HTTP Host Header.

References

1. Fielding, Group & Mogul, Jeffrey & Nielsen, Henrik & Masinter, Larry & Leach, Paul. (2000). Hypertext Transfer Protocol -- HTTP/1.1. Internet RFCs. 
2. Suresh, Meenakshi & Amritha, P.P. & Kumar Mohan, Ashok & Kumar, V.. (2018). An investigation on HTTP/2 security. Journal of Cyber Security and Mobility. 7. 161-180. 10.13052/jcsm2245-1439.7112.
3. https://developer.mozilla.org/en-US/docs/Web/HTTP/Status
4. Alam, Sawood & Cartledge, Charles & Nelson, Michael. (2014). Support for Various HTTP Methods on the Web. 
5. Buchanan, William & Helme, Scott & Woodward, Alan. (2017). Analysis of the Adoption of Security Headers in HTTP. IET Information Security. 12. 10.1049/iet-ifs.2016.0621. 
6. https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Host 
7. https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Forwarded-Host 
8. https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/17-Testing_for_Host_Header_Injection
9. https://nvd.nist.gov/vuln/detail/CVE-2020-11814