With HTTP Parameter Pollution (HPP) attacks, threat actors can hide scripts and processes in URLs. First discovered in 1999, this technique can also allow threat actors to pollute the parameters in the URL and the request body. This could lead to behavior changes in the app, such as cross-site scripting, privilege changes or granting unwanted access.

HPP remains a risk to watch out for today. Read on to discover how HPP attacks work and how to spot them.

The impact of HTTP parameter pollution

An attacker can use an HPP attack to perform many different unwanted actions. They can override the existing hardcoded HTTP parameters, modify the application behavior and access and exploit the user-uncontrollable variables. HPP attacks also enable people to bypass input validation checks and web application firewall (WAF) rules. It opens up routes to attacks, including cross-site scripting (XSS), structured query language (SQL) injection. HPP attacks can be performed by polluting HTTP GET/POST requests by injecting multiple parameters with the same name holding different values and kept apart by delimiters.

Types of HTTP parameter pollution

HPP can be classified into two types: client side or server side. Different web servers behave in different ways when they receive multiple parameters with the same name since ways to parse parameters vary. Client-side or server-side HPP attacks are possible depending on the way requests are handled.

For example, PHP/Apache-based apps use the last occurrence of the parameter, while Jakarta Server Pages (JSP)/Tomcat-based apps use the first. The table below shows how different languages and web servers manage this.

Client-side HPP

A client-side HTTP Parameter Pollution attack is related to the client or user environment, meaning the user’s actions are affected and will trigger a malicious or unintended action without their knowledge. This risk arises when an app embeds user input in URLs in an unsafe manner. An attacker can use this opening to construct a URL that, if visited by another user, will modify URLs within the response by inserting more query-string parameters that override existing ones. This may result in links and forms working in ways they weren’t meant to be used. For example, it may be possible to modify an invitation form using HPP so that the invitation is delivered to a different recipient.

This might have a greater or lesser impact depending largely on what the affected app can do. Even with an app that has no direct impact on its own, an attacker may use it in conjunction with other openings to make the overall attack worse.

Example: A movie rating site

Consider a movie rating website. People can give ‘likes’ or ‘dislikes’ for a movie. This example website uses two href links (Link A and Link B) containing two parameters, ‘mname’ and ‘mrating’. Mname holds the name of the movie for which the rating is given, and mrating holds the value of either likes or dislikes for any given movie.

URL: http://host/movie.jsp?mname=littlestar

Link A: <a href=”rate.jsp?mname=littlestar&mrating=like“>Likes for LittleStar movie</a>

Link B: <a href=”rate.jsp?mname=littlestar&mrating=dislike“>Dislikes for LittleStar movie</a>

Let’s assume the marketing team wants more likes for the movie “LittleStar”. So, the attacker using HTTP Parameter Pollution creates and shares the trigger URL to the victims: http://host/movie.jsp?mname=littlestar&mrating=like

An attacker injected the polluted parameter ‘mrating’ with a value of ‘like’. When the victims click on the doctored website, they are rerouted to the site which contains two injected links (Link A1 and B1 for the movie “LittleStar”).

Link A1: <a href=”rate.jsp?mname=littlestar&mrating=like&mrating=like”>Likes for LittleStar movie</a>

                                                                  Injected Parameter

Link B1: <a href=”rate.jsp?mname=littlestar&mrating=like&mrating=dislike”>Dislikes for LittleStar movie</a>

                                                                   Injected Parameter

The honest requests Link A and B have been polluted by adding another parameter (mrating) with the respective payloads. In this case, Link A1 and Link B1 become malicious href links. Since the app is designed on JSP in both links A1 and B1, the first occurrence of the similar parameters (the injected parameter) will be returned to the app and the second will be ignored. No matter which links the victim clicks on, the app will consume the mrating=like parameter in both href links, thus rendering more likes to the movie “LittleStar.”

Server-side attacks

So, the goal of the attacker in a client-side attack is to attack other users. In the server-side variant the attacker could use an at-risk web app in several ways. They could access protected data or perform actions that either are not permitted or not supposed to be run on the server side.

Server-side attacks can be done by injecting a similar parameter into existing values or by using parameters not visible to the end user.

Example: Robbing a bank

Let’s examine a classic example of a bank transaction to see how the HTTP Parameter Pollution attack could happen at the server side.

Flow Chart of Server-side Parameter Pollution

In the example, Bob is transferring $10 to Alice by entering a dollar amount and choosing the transfer account.

The request for the transaction will be as shown below:

POST /transfer.php HTTP/1.1

Host: bank.com

—

Connection: close

amount=10&payee=Alice

There are two parameters in the request sent to the server: the amount to be transferred and the payee. Once the request hits the server, another request is sent from the server to the back-end payment gateway. This is where the actual transaction takes place. Now, the request from the payment gateway looks something like this:

http://paygate:8080/?payer=Bob&payee=Alice&amount=10

Next step: Add a parameter

This request is similar to the previous one, but there is an additional parameter: payer. The parameter ‘payer’ is not present in the original request from the app, because the attacker could easily modify it and transfer all the money from any account. To prevent this, the server uses the payer’s cookie to get the name and then adds it at the back-end request to avoid changing the value.

The payer value cannot be changed. However, we can still use HTTP Parameter Pollution to inject a similar parameter with a different value. In this example, the payment gateway is written in PHP running on Apache. So, an attacker can add two extra parameters at the end of the existing parameters.

We already know PHP/Apache will consider only the last occurrence of the parameters, and the first occurrence will get ignored.

The payment gateway will see this:

payer=Alice&payee=Bob&amount=1000

POST /transfer.php HTTP/1.1                                                                200 OK

Host: bank.com                                                                                   Transaction Successful

—

Connection: close

amount=10&payee=Alice&payer=Alice&payee=Bob

When the payment transfer happens, the money will be debited from Alice’s account and credited to Bob’s account. Thus, Bob could steal all of Alice’s money through this attack.

Do web application firewalls make a difference?

The attack shown above is a type of direct-server attack where there is no app firewall, such as a web application firewall (WAF), in place. When there are app firewalls in place for protection, attackers can still bypass them.

Some WAFs may check and validate only a single parameter occurrence, either the first or the last one based on the method used. This attack is based on how the server parses the parameters with the same names.

WAF HTTP Parameter Pollution rules could be bypassed under a couple of different cases. It could be done when the server takes the last occurrence of the parameters and the WAF rule is designed to check only the first occurrence, or vice versa. Or, it could happen when the server joins two of the same parameters with different values and the WAF rule is designed to check them one by one.

How HPP bypasses firewall rules

Take the following example. Here, an HTTP Parameter Pollution attack can be used to bypass WAF rules in order to perform cross-site scripting.

To bypass the firewall rule, consider the following URL: http://myapp/vul.cgi?par=val

For HPP to be successful in the above URL/app, an attacker can add an extra parameter at the end of the URL with the same name but with a different value. The request would look like this: http://myapp/vul.cgi?par=val1&par=val2

In this case, since firewall rules are applied, what the app does is not changed. However, this rule can be bypassed by adding an XSS/SQL payload such that the attack could still be performed.

An attacker could split the malicious XSS/SQL payload into two parts and insert the two different values in the same parameters.

http://myapp/vul.cgi?par=”><img src=a onerror=al&par=ert(1)>

The above XSS payload “><img src=a onerror=alert(1)> is accepted and executed by the server after bypassing the firewall.

How to prevent HTTP parameter pollution

There are several ways to protect against HPP. 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. Beware of multiple instances of similar parameters. Lastly, use only common sense safe methods of navigating web technology and languages.

To protect these types of apps, the WAF should also interpret the HTTP request in the same way the app would. In addition, be aware of the weaknesses of specific app components and use strict filtering. Staying alert to these openings will help you spot HTTP Parameter Pollution before it hurts.