Can misconfigured HTTP request headers be as dangerous as parameters sent to the server? The short answer is: absolutely.
HTTP headers are typically seen as routine metadata automatically sent from a browser (or other sources) to a server. They help servers understand client requests, manage authentication, store cookies, and track user behavior. However, headers can also be consumed by various backend components for reasons unknown to the client.
For penetration testers and malicious hackers, HTTP headers present a lucrative but often overlooked attack surface. In my experience, security researchers tend to focus more on parameters while neglecting headers. Yet, unvalidated or misconfigured headers can lead to severe security vulnerabilities, including bypassing security mechanisms, subverting business logic, and stealing sensitive data.
In this article, I will demonstrate three interesting attacks that showcase different ways to exploit HTTP request headers. This is a starting point, covering both well-known and more advanced techniques that will be expanded in future discussions. Enjoy!
SQL Injections in Consumable Headers
Everything that is stored in a database can be vulnerable to SQL injection attacks. This classic attack is a fundamental finding for any penetration tester and a highly valuable target for malicious actors.
But why would developers store header values in a database? There are several reasons. For instance, the User-Agent or Referer headers might be logged for tracking purposes or analytics.
I have encountered multiple real-world scenarios where applications stored the User-Agent header in a database for statistical analysis. Here’s a simplified example of such an application:
- The application logs every visitor’s User-Agent for tracking purposes.
- The response body mentions that statistics are being gathered (though in real-world applications, this may not be explicitly stated).
- Testing reveals that the User-Agent header behaves differently when modified.
For presentation purposes, following application stores everyone’s User-Agent for tracking statistics – this is also mentioned in response body:
Of course, realistically this won’t be a case that application inform about gathering statistics, however this one reveal this information to user.
As for usual testing, let’s assume we tested all other parameters and headers, however we encountered that User-Agent header behaves differently.
Sending unmodified HTTP request to server:
Sending modified HTTP request to server, with added apostrophe reveals a HTTP 500 INTERNAL SERVER ERROR:
Again with additional apostrophe closing database request:
‘Classic disclosure of the fact, that indeed It may be vulnerable to SQL Injection. Using the Sqlmap toolkit reveals that this parameter is indeed susceptible:
Showcase of dumping credentials via vulnerable User-Agent parameter:
Although storing plaintext password is far-fetched scenario, as it would be normally stored in more secure way or even encrypted, however it proves that HTTP request headers can also be an vector for injections attack (all types, not even SQL).
X Headers Family
Some headers were created to help web applications and proxy servers identify the origin of a request sender. Because of this, these headers play a crucial role in logging, analytics, and load balancing. However, when improperly validated, they can become security liabilities, allowing attackers to spoof identities, bypass access controls, or manipulate request handling.
For instance we have X-Forwarded-For which Specifies the original host of the request before passing through proxies. If any component of the web application is secured by configuration that allows access only from certain IP addresses (or localhost) and moreover it honors this header, it can be easily abused to get unauthorized access to the functionality, for example: admin panel.
Netlog application has admin panel as one of the functionality, when regular user is trying to access it, it response with 403 FORBIDDEN revealing that it should be accessible only by Admins:
It means that this component probably require authentication, however sometimes, especially developers want to “secure” some resources as such by adding rule that it can be only accessed from certain IP or range. This can actually add to security, if there is a proper security layer like authentication based access, however, if this adding authentication is omitted, and application relies only on origin of requests, this is prone to be abused.
Often server will not reveal to us that it honors some headers – sometimes it does, returning various error. This time, server does not return any information if any injected header is working. Let’s again assume, that attacker is persistent and is trying all types of headers and basic IP addresses, either from public wordlists or custom built. After injecting various IP addresses in X-Forwarded-For, it is revealed that one of the addresses responded with different length:
192.168.1.100 value allowed to sneak through the “security mechanism” revealing administrator panel, without knowing credentials:
This issue and all other related to X Family headers has wreaked havoc in past in many applications, even matured ones, as this vulnerability led to many unusual occurrences. Worth mentioning is also fact, that this setting “127.0.0.1” local host value, was spotted in the wild plenty of times, because solutions were accepting “itself” and allowing request pass through. Other interesting headers that can work in similar fashion are:
- X-Forwarded-Host.
- X-Real-IP.
- X-Client-IP.
- X-Forwarded-Proto.
- X-Originating-IP.
There a lot more headers that can interact with services, highlighting similar outcome.
I Need Your Password Reset Token
When I started my career I was asked, what malicious can be done with Host header, I was not ensure, I never thought about this, apart from unexploitable self-redirection. Experience taught me well, and it is clearly to me and should be to all, that Host header manipulation can lead to serious repercussions, although this depends on context and functionality.
The Host header specifies which domain or IP address the client wants to communicate with. It is crucial for:
- Virtual hosting (multiple domains on the same server).
- Routing requests to the correct backend in load balancers and reverse proxies.
- Generating absolute URLs in web applications.
Many web applications use the Host header to generate links, especially for:
- Password reset emails.
- Verification links.
- OAuth redirections.
If an application blindly trusts the Host header without proper validation, an attacker can inject a malicious hostname to receive sensitive links.
To showcase this vulnerability I will use another component of Netlog a password reset. Of course password reset functionalities looks differently for each of product, however for understanding the attack, this will be more than enough. Application allows to reset password by providing email associated with account in application:
contact[at]offensiveblueprint.com email is provided:
Reset token link was sent to the pointed email, that is associated with account, it can be observed in client:
But what happens if Host header is changed, in this case it was changed to: “zsuperevilsite.com”:
View from perspective of victim:
So what you may ask? If you know user or email in vulnerable application (depending on approach), you may sent request with changed host, that points to controlled by you server, and when victim will click on link, it would send GET request to your server, thus giving you user reset token, that will allow you to change password effortlessly.
This vulnerability can differ and often will not work, or will require additional steps, however it is worth always testing for such possibilities.
Recap
For penetration testers and security researchers:
- Always test HTTP headers.
- Explore uncommon headers and read relevant RFCs.
- Understand that headers can expose vulnerabilities in unexpected ways.
For blue teamers and developers:
- Sanitize all user input, including HTTP headers.
- Remove unnecessary headers from production environments.
- Never rely solely on IP-based restrictions for authentication.
- Be aware of potential header abuse and enforce strict validation.
This article only scratches the surface of header-based attack vectors. With careful testing and awareness, security teams can proactively identify and mitigate these threats before they become real-world exploits.
