Detailed Guide on HTTP Parameter Pollution

What Is HTTP

HTTP (Hypertext Transfer Protocol) is a protocol designed to fetch resources such as HTML documents. It is the foundation of the World Wide Web and is used to communicate and transfer data between client and server. 

An HTTP request has several parts like HTTP version type, URL, HTTP method(GET, POST, etc.), HTTP request headers, and Optional HTTP body.

What is the HTTP parameter?

HTTP parameter is a placeholder for passing arguments between client and server.

Now the easy way “HTTP parameter is a place in the URL or Request/Response Body, where the client(browser) can send some specific data to Server(Requested Server) and vice versa”. 

As an example, here the name and amount are two parameters, and “Pranjal” and “1000” is the value of those parameters, which is going to be transferred to the requested server( 

HTTP parameters have 3 parts :

  1. Name of parameter
  2. Equal Sign(=)
  3. Separator(&)

This system works for both GET and POST, HTTP Methods.

What Is HTTP Parameter Pollution?

HTTP Parameter Pollution is a vulnerability where an attacker adds multiple parameters with the same name holding malicious value, thus the attacker makes the server do something which should not happen. 

Not just this using HTTP Parameter Pollution an attacker can bypass the firewall and find other vulnerabilities as well such as XSS, SQLi, etc. 

The HTTP Parameter Pollution attack can be performed by polluting both HTTP GET/POST requests.

Impact of HTTP Parameter Pollution

The impact depends on the station you are in. These are some common impacts of HPP:

  • Authentication Bypass
  • Captcha Bypass
  • Filter Bypass
  • Privilege escalation
  • Business Logic Abuse

Types of HTTP Parameter Pollution

There are two types of HTTP Parameter Pollution vulnerability as client-side and server-side. 

Now different web servers act differently when they receive multiple parameters with the same name since the ways to parse those parameters vary. 

Whether it’s client-side or server-side HTTP Parameter Pollution attacks are possible depending on how the server handles a web request.

For Example, PHP/Apache based web applications use the last occurrence of the parameter, while JSP, Servlet/Apache Tomcat based web applications use the first occurrence. 

Below the table will show you the different behavior of HTTP Parameters in different web servers.

ASP.NET/IISAll occurrences concatenated with a comma.param=val1,val2
PHP/APACHELast Occurrence Onlyparam=val2
IBM HTTP ServerFirst occurrence onlyparam=val1
PHP/ZeusLast occurrence onlyparam=val2
JSP, Servlet/Apache TomcatFirst occurrence onlyparam=val1
JSP, Servlet/Oracle Application ServerFirst occurrence onlyparam=val1
JSP, Servlet/JettyFirst occurrence onlyparam=val1
IBM Lotus DominoLast occurrence onlyparam=val2
mod_perl,libapreq2/ApacheFirst occurrence onlyparam=val1
Perl CGI/ApacheFirst occurrence onlyparam=val1
mod_wsgi (Python)/ApacheFirst occurrence onlyparam=val1
Python/ZopeAll occurrences in list(array)param=[‘val1′,’val2’]

The following examples will show you how different web application is parsing the same parameters differently. 

We are using Google Search Engine for the first example, 

Enter the following URL:

As you can see in the screenshot, the same parameter q is being used three times. 

In this case, Google Search Engine concatenates the three values with a space in-between, thus the final output looks like “web application security pranjal singhal”.

For the second example, we are using the Yahoo! search engine. 

Enter the following URL:;_ylt=Ajxtx6DKiSkS1pjEfg6zSMWbvZx4?p=web&p=application&p=security&p=pranjal&p=singhal

Here we used the same query as we used for google search, but you can see in the example that Yahoo! only parsing the last parameter, therefore the output become “singhal “.

This shows how each web server acts differently when parsing parameters.

How To Exploit HTTP Parameter Pollution Vulnerability

Now that you have the basic idea about HPP, let’s move on to a practical demo. Suppose the server-side code is something like below.

Here you can see the webserver is taking input from two parameters, amount and recipient. Now if the attacker sends a crafted web request like below.


Here the attacker has added “%26action%3dwithdraw” which is &action=withdraw” if URL decoded. This is an extra parameter “action”, but wait where did it come from? 

Now after the attacker sends the crafted web request, the frontend will build the following back-end request.

Now as you can see in the image, the frontend is creating a back-end request by adding a new parameter “action”. 

Then the attacker’s payload is getting decoded and executed, and when it executes the first parameter “action=transfer” is getting overwritten with “action=withdraw”. 

This is just one of the many ways of exploiting HPP. 

As a Bug Hunter, we don’t have permission to do malicious action, that’s why I am keeping this example very simple. Remember different web servers handle the inputs differently.

Another example using  OWASP Mutillidae 2. HPP in the voting system.

A normal request will look like this.

And this will be the output. The voting number will increase according to the vote request. Now let’s add a new parameter “choice=pranjalsinghal” and the requested URL is

Here you can see the website ignored the first parameter “choice=nmap” and executed the second parameter “choice=pranjalsinghal”. This way we are able to add a new choice name. 

Now another example of privilege escalation using HPP.

Here this server-side code behaves something like this.

If the user requests the URL as below.


will become,


Now if the attacker injects a new parameter of the same name with a different value like below.


Which is “abc&action=edit” if URL decoded. Now the final request will look like this.


Here you can see the webserver is added the action parameter with edit permission. This way the attacker will get edit permission of the page instead of view.

Some useful resources for HTTP parameter pollution

Here I am giving you some resources which I looked into when writing this blog. This also might help you.

Final Note

Thanks for your time! I hope, now you can detect and exploit the HTTP Parameter Pollution bug. 

If you like this, make sure to share it with others so they can leverage this information. As always, for any doubts or questions, please leave a comment below, or reach me on Instagram.

Leave a Comment