Behind the Scene : HTTP Parameter Pollution

Let’s take an example so that you’ll never forget the concept. Let suppose, I have given you a puzzle and also with that, I have provided you a method to solve that. But as a hacker you told me, Listen Ethical kaps I am not going to go your way. I’ll choose one of mine to solve it. Similar is the case with this Vulnerability, Here you tell the application that I am not going to go your way. Rather, I’ll choose my own path.(This process of choosing our path, of our own, basically refers to Pollution in Parameter Pollution).
Some of you might not understood this, but no worries stay tuned!!!!!

See this practical example to understand the concept more clearly.

What I am doing over here is, simply providing the SQL query in the one of the parameter(prodID) that I have found in my target :

But now as a hacker I’ll do it in hacker’s way. So what I did :

I basically, broke the simple query into multiple parts & polluted the HTTP request by my parameters. This evasion technique in which we build our own HTTP request to manipulate the information or to retrieve the data is known as HTTP Parameter Pollution.

At First, you need to identify which parameters are reflecting on the target application and which not. And how exactly you are going to know that? For this I have broken down the issue in 2 scenarios. You can encounter these two situations:-

Scenario 1

When you already know that :-

Application is coded in which language.On which server it is running.

If you know this, then you are half way done to find this Vulnerability. Refer the chart below. It will become super easy for you to identify which injected parameter the application is going to accept.

Just have a look at this chart. (You don’t need to learn this. Just go through it and take a general Idea)

Reference:- https://owasp.org/www-pdf-archive/AppsecEU09_CarettoniDiPaola_v0.8.pdf

Scenario 2

When you don’t know much about the target :-

So this is another obvious situation that you may face while hunting this type of vulnerability, where you have no clue about which parameter is going to get executed ? The clear cut answer to this question is manual testing which you need to do to find out, which parameter is acting in an interesting manner.

But there’s a hint that your parameter may reflect in :-

the URI- using GET parameters.the request body- using POST parameters.the HTTP Headers- using Cookie header.

You need to act according to the situation and find out the vulnerable parameter/parameters.

Let’s get straight into it.

Now its the time to get clarification of all the theory. Sorry, I explained it way too deep but clarity should be our goal. Anyway, keep your motivation high we are about to cross the line!

Let suppose, the Web-App that you are targeting (https://ethicalkaps.com) is using PHP as the technology and has Apache Server at the backend. Refer point 3 (PHP/Apache) of the chart, it says that last occurred parameter will get executed.

I visited the URL and noticed one parameter (par1) that has value (value1) associated with it. This is just for an example point of view. In real target you may find different parameters (such as uid=,id=,price=,name=,to=,amount=,from=,url=,uri= etc..) It can be anything. You just need to manipulate and check what exactly is polluting the URL.

Now, in the image below, you can say that I have polluted the parameter or injected par2=“><svg/onload=alert(“EthicalKapsHere”)> as my payload to get executed. As I know (from the chart above) that last parameter is going to get executed.

So when I run this particular URL then I am going to get the output as:-

So in this case par2= was vulnerable and lead to XSS over here.

Note:- I would like to quote one more thing here that this is not the only way. You can also use encoding of characters and symbols to bypass any restrictions. And, if you watch closely to this vulnerability you can perform many other attacks. That I leave up to you, as it’s all your creativity and logics. I will not confine you to some particular list.

If you need to find out the hidden parameters in the application and want to save your time then you can go for automation. I personally prefer Arjun .

Reason being ?

It can handle different requests like GET/POST/POST-JSON etc.It can automatically handle the rate limits.You can directly export the results to BurpSuite/text file and it possess many other advantages that you’ll get to know when you’ll use it.

You can achieve many different objectives with HPP. For example :-

Bypass Web Application Firewall.Perform Client and Server side attacks etc..

For further Reference you can refer to below links. Probably the best link out there on internet :-

https://owasp.org/www-pdf-archive/AppsecEU09_CarettoniDiPaola_v0.8.pdf

So, this is it for this Article I hope you enjoyed it. I will come back to you with another #BehindtheScene. Till then, take care and Keep Hunting for good. Keep Digging and learning new stuffs.

If you like the content then, you can support me over here :- @buymeacoffee.com/ethicalkaps

See you in the next Article. Until then Cherish your life. Peace!

You can Follow me on Twitter, on Spotify to listen my writeups and on Instagram.