HTTP Parameter Pollution

HPP:

What is HTTP Parameter Pollution (HPP)?

HPP happens when a website gets multiple parameters with the same name, and the server or browser gets confused about which value to use.

Example:

https://example.com/profile?user=alice&user=bob

Now the question is:

· Should the website use alice?

· Or bob?

· Or both?

Different technologies handle this differently, and that confusion is the core of HPP.

Why does HPP happen?

Because:

· Developers assume only one parameter will be sent

· Attackers intentionally send extra parameters

· Server or browser trusts attacker-controlled values

This leads to unexpected behaviour

Where can HPP occur?

There are two types:

1. Server-Side HPP: The server/backend code processes parameters incorrectly.

2. Client-Side HPP: The browser / JavaScript processes parameters incorrectly.

Why HPP is Hard to Find?

Because:

· No clear error messages

· Behavior depends on:

o Programming language

o Framework

o Web server

· Requires trial and error

What Bugs Can HPP Lead To?

HPP can help find:

· Authentication bypass

· Authorization bypass

· Open redirect

· XSS (DOM-based)

· Logic flaws

· Payment manipulation

Server-Side HTTP Parameter Pollution:

What is Server-Side HPP?

Server-side HPP happens when you send extra or duplicate parameters to a server, and the server code gets confused and behaves in an unexpected way.

· You cannot see the server's code

· You can only:

o Send inputs (URL parameters)

o Observe outputs (response)

Why is it called server-side?

Because:

· The logic runs on the server

· Not in browser JavaScript

· The mistake happens in backend code (PHP, Java, Ruby, ASP, etc.)

Example:

Normal request (expected by server):

https://www.bank.com/transfer?from=12345&to=67890&amount=5000

Attacker Adds Extra Parameter (HPP):

https://www.bank.com/transfer?from=12345&to=67890&amount=5000&from=ABCDEF

What Can Go Wrong?

The application might:

· Validate first from

· Execute using last from

Result:

· Validation: Account 12345 (victim)

· Execution: Account ABCDEF (attacker-controlled)

Money stolen from another account. This is server-side HPP.

Why This Is Dangerous?

Because:

· No error

· No warning

· Looks like a valid request

· Happens silently

Important Point: Servers Behave Differently

There is NO universal rule for:

· Which parameter is used

· First, last, or all

That's why: HPP requires experimentation

Hidden Server-Side HPP:

New logic: https://www.bank.com/transfer?to=67890&amount=5000

· from is NOT in URL

· Server sets it internally (hidden from you)

You think: "I can't control from anymore". But maybe you can.

How to Test HTTP Parameter Pollution? (using Burp Suite)

Step1: Open Burp suite. Browse the site (http://testphp.vulnweb.com/) and note URLs as shown below in the Proxy->HTTP History.

Step2: See the URL which has parameters, like shown below:

Step3: See the rendered page for the original request.

Step4: Now change the parameter, as shown below:

GET /listproducts.php?cat=1&cat=2 HTTP/1.1

Clearly, the server used last value (of cat=2). This behaviour depends on backend language/framework.

Step5: To recheck if it actually uses last value, we changed the values again.

Clearly, it uses last value, as it used cat = 1 now.

Step6: Testing with multiple same parameters, but the 2nd parameter be something which is not present. Clearly a blank screen shown where the product was expected to be present.

Step7: Try encoding trick.

The server returned a database error.

The application is vulnerable to server-side HTTP Parameter Pollution. When duplicate cat parameters are supplied, the application processes them inconsistently, resulting in unexpected behaviour (empty product listing and in one case also shown the Database error). This indicates improper handling of duplicated parameters on the server side.

Why this conclusively proves server-side HPP?

PHP parameter type confusion

In PHP:

· cat=1 → $_GET['cat'] = "1"

· cat[]=2 → $_GET['cat'] = array(2)

When both are present, PHP coerces cat into an array.

How to Test HTTP Parameter Pollution? (using FFUF)

Step1: Create an HPP wordlist

Paste the following words:

Step2: Look for the endpoint on which we want to test.

This tells us:

· The parameter cat directly affects server-side behaviour

· Different categories return different content

· This endpoint is HPP-testable

Step3: Run FFUF to detect Server-Side HPP

Now look at the polluted requests:

What this proves about the backend?

Parsing logic: Last parameter wins

The server processes:

?cat=1&cat=2 → cat=2

?cat=2&cat=1 → cat=1

This is server-side HTTP Parameter Pollution.

The application processes duplicated HTTP GET parameters without validation. When multiple instances of the same parameter are supplied, the backend applies the last-occurring value, leading to Server-Side HTTP Parameter Pollution (HPP). This behaviour may allow attackers to manipulate backend logic, bypass security controls, or chain with other vulnerabilities.

Vulnerability chaining with the Server-side HPP:

These commands download two web pages and count their size so we can quickly see that sending duplicate parameters (cat=1&cat=1') breaks the server logic and triggers an SQL error.

The application is vulnerable to Server-Side HTTP Parameter Pollution (HPP). By supplying multiple instances of the same parameter, an attacker can bypass input validation logic. The backend processes the last parameter value during SQL query execution, resulting in a SQL Injection vulnerability reachable only through HPP.

Client-Side HTTP Parameter Pollution:

What is Client-Side HPP?

Client-side HTTP Parameter Pollution (HPP) is a problem where an attacker tricks a website into adding extra URL parameters that the site didn't intend to include.This happens in the user's browser, not on the website's server.

The client-side HTTP PP example in simple terms:

1. The website expects a URL like this:

page.php?par=123

2. The site takes whatever is inside par and puts it into a new link, like:

page.php?action=view&par=123

3. An attacker changes the par value to:

123%26action=edit

· %26 is just another way of writing &

· So later, %26action=edit becomes &action=edit

Why %26 is important

• If the attacker used:

123&action=edit

the website would treat action=edit as a separate parameter and likely ignore it.

• But by using %26, the site thinks everything is still part of par.

What the site does wrong

· The site tries to protect itself by converting special characters for HTML.

· %26 becomes &, which looks safe in HTML.

· But when the browser uses the link, & turns back into &.

The final result

The browser ends up seeing this link:

page.php?action=view&par=123&action=edit

The attacker has secretly added action=edit.

How to protect against the Client-Side HPP?

1. Use proper URL encoding, not just HTML encoding

2. Never trust user input when generating links

3. Whitelist allowed parameters and values

4. Do not reuse raw query strings in HTML

5. Handle duplicate parameters safely on the server

Client-side HPP happens when user input is encoded for HTML but interpreted as URL parameters by the browser — proper URL encoding, strict validation, and safe link generation prevent it.

Note: Client-side HPP is reflected in View Page Source, not in Inspect Element.

HPP vs Open-redirect:

Note:

· Open Redirect: The website itself sends you to a malicious site.

· HPP: The website unintentionally lets an attacker change data sent to another service.

· If changing a parameter changes behaviour, try duplicating it once.

Using ParamSpider and wfuzz for HPP:

Testing on URL: http://testphp.vulnweb.com/

Step1: In terminal, Identify Parameters Using ParamSpider.

Command: paramspider -d testphp.vulnweb.com

Output:

Step2: Open the ".txt" file to see analyse the ParamSpider output.

Output:

You'll see URLs like:

http://testphp.vulnweb.com/artists.php?artist=1

http://testphp.vulnweb.com/product.php?id=1

http://testphp.vulnweb.com/listproducts.php?cat=1

http://testphp.vulnweb.com/search.php?test=query

These are HPP candidates because:

· Parameters control content

· Backend logic depends on them

Step3: Using wfuzz to Automate HPP Discovery.

Make a baseline request:

Command: curl -I "http://testphp.vulnweb.com/product.php?id=1"

Output:

Testing with multiple parameters:

Command:

wfuzz -c -z range,1–5 \

"http://testphp.vulnweb.com/product.php?id=1&id=FUZZ"

Output:

As per the output, testphp.vulnweb.com/product.php:

· Uses the same HTML template

· Same layout

· Same number of tags

· Only the product name / description changes

So:

· Character count stays the same

· Word count stays the same

· Line count stays the same

wfuzz compares size, not meaning. This is a classic false negative at the tooling level, not at the logic level.

Step4: Reverify at the browser, as we have done earlier. And done !

HTTP parameter pollution on bWAPP:

Testing on URL: http://itsecgames.com/

Step1: Open the bWAPP (OWASP VM machine -> IP on the browser).

Step2: Open the HTTP parameter Pollution section.

Step3: Now, enter your name and Press "Continue" button, following screen will appear.

Step4: Observer the URL

The parameters are movie, name and action.

Step5: Now, we will add one extra parameter (say movie) to check for HPP. First vote from your own.

First:

Second:

Step6: So now what we want is when any other users click any movie the vote must go to iron man by adding parameter.

If you click any other movie as your favourite the vote will only goes to the second movie because of HTTP parameter pollution vulnerability.

Note: We can identify web technologies using "Wappalyzer".

Using HPP for password reset:

Testing on:

https://www.hack-yourself-first.com/Account/Login?ReturnUrl=%2fAccount%2fUserProfile%2f1

Step1: Open the website in the browser of the Burp. Look for the forget password link, following screen will appear:

Step2: Enter the mail id to reset the password, keep intercept on. Following screen can be seen in the Burp:

Step3: Forward it to the repeater. In repeater it can be originally seen as:

Step4: For base case, test with the original one, following response can be seen:

Step5: Duplicate the parameter as shown below:

Step6: send this manipulated request:

Clearly, What the server replied is 'HTTP/2 302 Found' then

In simple terms:

· The server accepted the request

· It did not throw an error

· It processed the reset-password flow

· It redirected you to the "Reset Password Complete" page

So, the application did not reject duplicate parameters. Since, this website doesn't send any link to the mail, we can't directly say that HPP vulnerability is there, but yeah since duplicate parameters were allowed, we can say that it is prone to HPP.

Contact Me 📧 Email: adii.utsav@gmail.com 🔗 LinkedIn: https://www.linkedin.com/in/aditya-kumar-3241b6286/ 💻 GitHub: https://github.com/Rememberful