HTTP Parameter Pollution (HPP) is a type of injection attack that occurs when a target system accepts multiple parameters with the same name and handles them in a manner that might be insecure or unexpected. This type of vulnerability can be found on both the server-side and client-side.
How HTTP Parameter Pollution (HPP) Works
HPP tests the applications response to receiving multiple HTTP parameters with the same name; for example, if the parameter username is included in the GET or POST parameters twice.
When multiple parameters with the same name are sent to a server, different languages and frameworks handle these parameters in a different way. This is because there is no standard way for accepting multiple parameters with the same name.
The table below illustrates how web technologies behave in presence of multiple occurrences of the same HTTP parameter.
Given the URL and query string:
Web Application Server Backend
All occurrences concatenated with a comma
PHP / Apache
Last occurrence only
JSP, Servlet / Oracle Application Server 10g
First occurrence only
IBM Lotus Domino
Last occurrence only
IBM HTTP Server
First occurrence only
Python / Zope
All occurrences in List data type
NB: Unusual behaviours are a usual source of security weaknesses.
By itself, this is not necessarily an indication of vulnerability. However, if the developer is not aware of the problem, the presence of duplicated parameters may produce an anomalous behavior in the application that can be potentially exploited by an attacker.
Testing for HTTP Parameter Pollution Vulnerabilities
Information transfer using the HTTP protocol can be done in various ways, such as:
Within the URI – using the GET parameters
Within the request body – using the POST parameters
In the HTTP headers – using the COOKIE header
These are all valid places to test for HPP vulnerabilities. To proceed with our attack, we will aslo need to:
Identify the back-end server and parsing method used (Enumeration is key).
Assess injection points and try bypassing input filters using HPP.
Types of HTTP Parameter Pollution Vulnerabilities
Client-Side HTTP Parameter Pollution Vulnerability
The HTTP Parameter Pollution (HPP) Client-side attack has to do with the client or user environment, meaning that the user’s actions (i.e., access a link in a browser) are affected and will trigger a malicious or unintended action without the user’s knowledge.
An example of a typical HPP client-side attack includes a website that is vulnerable to HPP and a group of victims that will interact with the vulnerable website. An attacker, after identifying a vulnerable website, will create a vulnerable link with its HTTP parameters polluted and will send this link or make it publicly available through emails or social networks for naive and unsuspecting victims to click on. After the victims have clicked on it, the intended malicious behavior will be performed, affecting the users and the web application (application providers).
Server-Side HTTP Parameter Pollution Vulnerability
Objective: Transfer $100 from Jake to Attacker
In the HPP Server-side attack, the back-end environment of the web application will be affected. The attacker using HPP attacks will try to exploit the logic of the vulnerable web application by sending a triggered, or polluted URL, for example to access the database of a web application or perform unintended actions.
We have a payment gateway developed using PHP and running on an Apache Server. We perform a request to the payment gateway which looks as below:
For security purposes, the from=Attacker parameter is not coming directly from the website itself (because the attacker can modify it). The server uses your cookie to get your username (lookup) and then adds it to the back-end request to the payment-gateway.
So, we know we cannot change the value of the from parameter, but can we sneak in our own values?
Yes, we can!
If the server was improperly configured $100 would be taken from Jake’s account and transferred to the user account.
Though this is a very simple example, this is the foundation of Server-Side HPP: looking for different parameters and editing, adding or deleting from a request.
HTTP Parameter Pollution Vulnerabilities in the Wild
A critical HPP vulnerability was discovered in Blogger , the popular blogging platform. The bug allowed malicious users to take ownership of the victim’s blog by using the following HTTP request:
POST /add-authors.do HTTP/1.1
The flaw resided in the authentication mechanism used by the web application, as the security check was performed on the first blogID parameter, whereas the actual operation used the second occurrence.
Other HPP vulnerabilities in the wild included:
Whether or not HPP constitutes a serious vulnerability depends on the specific applications code. The impact can range from:
Bypassing security control mechanisms e.g. authentication.
Bypassing filters e.g. (Web Application Firewall).
Change the application flow
Additionally, an attacker can potentially override existing hard-coded HTTP parameters (e.g. prices of items in e-commerce website) to modify the behavior of an application, bypass input validation checks, and access and possibly exploit variables that may be out of direct reach for an attacker. HPP can also be chained with other bugs.
Detections of HTTP Parameter Pollution Vulnerabilities
Use a vulnerability scanner that can be able to detect such attacks.
Mitigations of HTTP Parameter Pollution Vulnerabilities
Accept parameters only where they are supposed to be supplied.
Make sure to perform an extensive and proper input validation. All user-supplied data, which is reflected in the HTML source code of the HTTP response, should be encoded according to the context in which they are reflected.
Configure a WAF to not allow multiple instances of the same parameter in a single HTTP request. This would prevent all types of this attack. However, this might not be possible in all cases, though, as some apps might need multiple duplicate parameters. They might be designed to send and accept multiple HTTP parameters of the same name in the same request.
HTTP Parameter Pollution server side, it’s always important to use URL encoding whenever you do GET/POST HTTP requests to an HTTP back-end to avoid special characters that may be used for HPP attacks
From the client-side point of view, use URL encoding whenever you are going to include user-supplied content within links, etc to avoid special characters that may be used for HPP attacks.