Oct 9, 20234 min read

HTTP Parameter Pollution (HPP)

Introduction

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:

http://example.com/?color=red&color=blue

Web Application Server Backend	Parsing Result	Example
ASP ASP.NET / IIS	All occurrences concatenated with a comma	color=red,blue
PHP / Apache	Last occurrence only	color=blue
JSP, Servlet / Oracle Application Server 10g	First occurrence only	color=red
IBM Lotus Domino	Last occurrence only	color=blue
IBM HTTP Server	First occurrence only	color=red
Python / Zope	All occurrences in List data type	color=[‘red’,’blue’]

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:

http://payment-gateway:8181/?from=Attacker&to=Jake&amount=100

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!

http://payment-gateway:8181/?from=Attacker&to=Jake&from=Jake&to=Attacker&amount=100

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

[…]

security_token=attackertoken&blogID=attackerblogidvalue

&blogID=victimblogidvalue

&authorsList=goldshlager19test%40gmail.com(attacker email)

&ok=Invite

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:

Implications

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.
Manual testing.

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.