The HTTP header injection vulnerability is a web application security term that refers to a situation when the attacker tricks the web application into inserting extra HTTP headers into legitimate HTTP responses. HTTP header injection is a technique that can be used to facilitate malicious attacks such as cross-site scripting, web cache poisoning, and more. These, in turn, may lead to information disclosure, use of your application in phishing attacks, and other severe consequences.
HTTP header injection is a specific case of a more generic category of attacks: CRLF injections. If the attacker is able to inject a CRLF sequence (carriage return and line feed) into the response, they are able to add various fake entries or change existing data: not just headers but even the entire response body.
What causes HTTP header injection vulnerabilities?
Just like most web application security vulnerabilities, HTTP header injection vulnerabilities (and CRLF injection vulnerabilities in general) are the result of overtrusting user input. If the developer of a web application uses external data directly in HTTP responses, it’s usually possible to perform an HTTP header injection attack.
For example, imagine that your business moved to a new domain and, for convenience, you want user bookmarks to still work. The original domain was example.com but now your site is available at example.info. If your regular user visits an obsolete URL such as http://www.example.com/page1, you want the web server to automatically redirect the user to the respective new URL: http://www.example.info/page1.
To achieve the above goal, you can build a simple web application at example.com that takes the path from the HTTP request and appends it to http://www.example.info/. If the developer of that application does not eliminate CR and LF special characters from the input data before appending it to the new base URL, an attacker may use this application to perform HTTP header injection attacks.
Anatomy of an HTTP header injection attack
HTTP header injection attacks are in many ways similar to cross-site scripting (XSS) attacks. As such, there are reflected HTTP header injection attacks and (less common) stored HTTP header injection attacks.
Reflected HTTP header injection
Imagine that you are the owner of the example.com domain and that an attacker wants to take advantage of your HTTP header injection vulnerability described above. They prepare a phishing campaign and send the following URL:
http://example.com/page1%0d%0aLocation:vulnweb.com
As a result of the HTTP header injection, the CRLF characters are inserted into the response and followed by a new Location: header. The web browser (depending on the browser type and configuration) will redirect the user to the attacker’s site (here: vulnweb.com).
Stored HTTP header injection
Stored HTTP header injection vulnerabilities and related attacks are quite rare. In this case, malicious user input is stored by the web application, for example in a database, and then used directly in the HTTP response sent to other users.
Just like in the case of stored cross-site scripting vulnerabilities, stored HTTP header injection is more dangerous because it may potentially affect all users that visit your website or use your web application.
Consequences of HTTP header injection attacks
We described the simplest case of an HTTP header injection attack above – the attacker may exploit an HTTP header injection vulnerability directly to use your domain as a basis for a phishing attack.
However, there are more potential consequences of HTTP header injection. For example, the attacker may use HTTP header injection to inject new headers that loosen the same-origin policy security restrictions, thus making it possible to perform other attacks that would otherwise be impossible, for example, CSRF.
Another potential use of HTTP header injection attacks is HTTP response splitting. In such a case, the attacker not only injects new HTTP response headers but also the entire response body. Using the Content-Length header, they are able to make the victim’s browser completely ignore the legitimate body of the response (and remaining legitimate headers).
How to detect and avoid HTTP header injection vulnerabilities
The best way to detect HTTP header injection vulnerabilities is to use a renowned web vulnerability scanner such as Acunetix®. Acunetix has tests for CRLF injection and specific tests for HTTP header injection as well. Since the impact of CRLF injection, in general, may be severe (similar to the impacts of cross-site scripting), these vulnerabilities should not be treated lightly despite not being specifically mentioned in the OWASP Top 10.
Since HTTP header injection is the result of improper neutralization of CRLF sequences, the best way to avoid such vulnerabilities is to encode CRLF sequences from user input before using it in HTTP responses. This also prevents consequences of other attacks that exploit CRLF injection, which can even lead to sensitive information breaches, corruption of log files, or code execution.
Get the latest content on web security
in your inbox each week.
THE AUTHOR
Principal Cybersecurity Writer
