HTTP parameter pollution is something which manipulate according to how a web applications treats the parameters which receives during http requests, here vulnerability found when an attacker injects extra parameters into a request and sometimes the target website trust them, this leads to unexpected behaviors .
In other words attacker craft a HTTP request in order to manipulate or retrieve hidden information
HPP vulnerability can be found on both server side and client side
lets see in SERVER-SIDE HPP
here in server-side hpp, here to get some unexpected code returns from website, attacker injects some unpredicted code in server side to get results, when he make a request to website , the site’s servers process the request and return a response, they don’t just return webpage but also sometimes website runs code based on information they receive from the URL that is sent,
hpp can be also used to bypass several web application firewalls (waf)rules, in some wafs only validate a single parameter occurrence
HPP Server-side attacks can also be used for cross-channel pollution and to bypass CSRF tokens
lets supposer there is web technology is ASP.NET/IIS, an attacker can send the request to server
Since ASP.NET/IIS concatenates the values of the same parameters, the end result will be <script prompt”…”>. Consequently, an attacker can expand this into a complete cross-site scripting attack.
If there’s a any Application Firewall ahead of this application then it’ll check every incidence of the parameter singly against the foundations for injection attacks. As a result, the online application firewall can check the primary parameter which is able to not match any of the injection attack rules since this can be not a malicious payload. Then it’ll create constant check for the second parameter that equals once more, this can be not thought-about as a dangerous payload and can not raise any alerts. even so, as mentioned before, ASP.NET/IIS can concatenate these values, supported however the technology parses these occurrences, leading to capital punishment associate XSS attack (if it had been enlarged in a very complete XSS payload).
Now lets see in CLIENT-SIDE HPP
Client side HPP vulnerabilities allow attackers to inject extra parameters into a URL to create effects on a users end
here client side attack has to do with user’s action are affected and will trigger a malicious code or unintended action without the users knowledge hpp client side attacks can be reflected hpp , stored hpp and action forms with post method , another hpp client attacks side attack is dom based attack
lets take a scenario is webmail service website from where user can view and delete his/her email
the link to view an email is:
<a href=”viewemail.jsp?client_id=79643215&action=view”> View </a>
the link to delete an email is:
<a href=”viewemail.jsp?client_id=79643215&action=view”> Delete </a>
here when the user clicks on any of those links the action will be performed the two links are built from the url. the ID will requested and added embedded in the href link together with according action. Thus:
href_link=”viewmail.jsp?client_id=” +ID +”&action=abc”
so now we can see client_id is vulnerable to HPP, an attacker creates a url and injects another parameter ‘action’ by encoded query eg%26 after the client_id parameter , this parameter holds the value ‘delete’:
After the creation of the malicious link, the page now contains two links which are injected with an extra action parameter. Thus:
<a href=viewemail.jsp?client_id=79643215&action=delete&action=view > View </a>
<a href=viewemail.jsp?client_id=79643215&action=delete&action=delete > Delete </a>
as shown in the above table Jsp will parse the two same parameters (action) and will return the first value. JSP query Request.getParemeter(“action”) will return ‘delete’ in both cases,
This is a simple example how an attacker can exploit an HTTP Parameter Pollution vulnerable website and cause malicious code to run or be executed without being detected.
Thank you for reading this and have a nice stay there!