What is HTTP Header Injection?

HTTP Header Injection is a web Security Vulnerability where the web application dynamically constructs headers from the user’s supplied input.

HTTP works on the Request/Response Model. The user requests a resource from the web server and the web-server resounds accordingly. HTTP headers are used to request the necessary resources. Headers can be categorized into two major categories. The request and the response headers. The vulnerability occurs when an input supplied by the user is included in the HTTP Response. This can lead to a lot of issues such as bypassing CSRF protection, redirecting users to different domains or bypassing the CSRF protection sometimes.

Causes

One of the major causes of HTTP Header Injection is CRLF Injection. CRLF Injection occurs when a HTTP request is interred in a different way by a reverse proxy and in a different way by a web server. CRLF Injection can be used by attackers to bypass restrictions, access Forbidden pages and even cause web cache poisoning.

For Example:

Let’s consider a website that is vulnerable to Header Injection. It takes the URL and prepends a location header to it. Suppose the URL IS www.vulnearblesite.com/page1.php

The Back-end takes the URL, removes the domain name and changes it to www.sub1.vulnerable.com and then appends page1.php to it. It thus becomes, www.sub1.vulnerable.com/page1.php

It then responds with:

Location: www.sub1.vulnerable.com/page1.phpNote: The Location header is used by the browser to redirect to the mentioned site.

An attacker can leverage this to send a victim to a malicious site.

For instance, if the URL were,

www.vulnerablesite.com/page1.php%0d%0a %0d%0aLocation:%20www.evilsite.com

This, when parsed by the back-end, would result in addition of a new Location header as there are few new line characters that has been added to the URL (%0d%0a) so the server interprets that as new line and a new header gets added to the request with a value of www.evilsite.com. This can lead the victim to a malicious website owned by the attacker. It can be used for phishing purposes, adding a header to bypass different types of security protection such as CSRF, adding cookies etc.

From the server's browser's perspective this would look as:Location: www.sub1.vulnerable.com/page1.php
Location: www.evilsite.com

Consequences

This can lead to HTTP Host header injection, which is a type of HTTP Header Injection. In which the attacker injects the host header and the website redirects the user to the defined header.

Sometimes the website uses the host header to generate the password reset tokens i.e the domain in the host header is directly used in the domain of the password reset so it can lead to the compromise of the password reset token.

This can also lead to cache poisoning if the application is serving the cached web pages, Cross Site Scripting, and Phishing attacks as well.

Host Header Injection:

Multiple subdomains can be hosted on a single web server. The Host header instructs the web server which subdomains to use in order to retrieve the resources. If it is not correctly hand loaded by the web server, it can be the target of a variety of assaults.

For example, the web server takes the host header from the user’s request and uses it to fetch important.js files. This file is hosted on the server and complete URL has not been added in the source code, only a / with the file name, hence it will use the host header to as the domain and will append important.js after that.

Server-Side Codeinclude(‘$_SERVER[‘host’]’.’/important.js’)

When you send a request to the web-server with the host as vulnsite.com, the following happens due to the insecurely written code in the back-end.

Host: vulnsite.cominclude(“vulnsite.com/important.js”);

If it is vulnerable to host header injection, it can be used by attackers to include vulnerable scripts. If the attacker supplies in evil.com in the host header (Host: evil.com) the following would occur.

include(‘evil.com/important.js’);

Because many businesses utilize web cache servers, this response would be cached by the web server and would then be served to other users as well, which might lead to phishing, cookie theft using XSS, and a variety of other malicious activities.

Remediation

• Newline characters should be permitted in user inputs or in the URL, and whitelisting should be used where it is required to prevent them from being used.
• Check that you do not support any additional headers that could be used to construct similar attacks, such as X-Forwarded-Host, as this could be a red flag. Keep in mind that these may or may not be supported by default in your environment.
• The current domain should be manually set in a configuration file when using absolute URLs, and the value of this value should be used instead of the Host header when using relative URLs. For example, the threat of password reset poisoning would be eliminated with this method of operation.

Labs for Practice

You can do the practice on these labs

• Password Reset Poisoning via host header
• Authentication Bypass via Host header

Conclusion

The Web has become a lot more sophisticated. It is easy to become vulnerable to various vulnerabilities if the best coding and security practices are not applied. It is therefore important to perform a penetration test on your websites at regular intervals so that your websites are safe from vulnerabilities and attackers.