HTTP Parameter Pollution, or HPP, occurs when a website accepts input from a user and uses it to make an HTTP request to another system without validating that user’s input. This can happen one of two ways, via the server (or back end) and via the client side.
On StackExchange, SilverlightFox provides a great example of a HPP server side attack; suppose we have the following website, https://www.example.com/transferMoney.php, which is accessible via a POST method taking the following parameters:
When the application processes this request, it makes its own POST request to another back end system, which in turn actually processes the transaction with a fixed toAccount parameter.
Separate back end URL: https://backend.example/doTransfer.php
Separate back end Parameters: toAccount=9876&amount=1000&fromAccount=12345
Now, if the back end only takes the last parameter when duplicates are provided and suppose a hacker alters the POST to the website to submit a toAccount param like this:
A site vulnerable to an HTTP Parameter Pollution attack would forward the request to the other back end system looking like:
In this case, the second toAccount parameter submitted by the malicious user could override the back end request and transfer the money into the malicious user’s submitted account (99999) instead of the intended account set by the system (9876).
This is useful if an attacker were to amend their own requests, which are processed through a vulnerable system. But it can be also more useful to an attacker if that attacker can generate a link from another website and entice users to unknowingly submit the malicious request with the extra parameter added by the attacker.
On the other hand, HPP client side involves injecting additional parameters to links and other src attributes. Borrowing an example from OWASP, suppose we had the following code:
<? $val=htmlspecialchars($_GET[‘par],ENT_QUOTES); ?>
<a href=”/page.php?action=view&par=’.<?=$val?>.'”>View Me!</a>
This takes a value for par from the URL, makes sure it’s safe and creates a link out of it. Now, if an attacker submitted:
the resulting link would look like:
<a href=”/page.php?action=view&par=123&action=edit”>View Me!</a>
This could lead to the application then accepting the edit action instead of the view action.
Both HPP server side and client side depend on which back end technology is being used and how it behaves when receiving multiple parameters with the same name. For example, PHP/Apache uses the last occurrence, Apache Tomcat uses the first occurrence, ASP/IIS uses all occurrences, etc. As a result, there is no single guaranteed handling for submitting multiple parameters with the same name and finding HPP will take some experimentation to confirm how the site you’re testing works.
Types Of HTTP Parameter Pollution
1] Server-Side HPP
To test for HPP vulnerabilities, identify any form or action that al-lows user-supplied input. Query string parameters in HTTP GET requests are easy to tweak in the navigation bar of the browser. If the form action submits data via POST, the tester will need to use an intercepting proxy to tamper with the POST data as it is sent to the server. Having identified a particular input parameter to test, one can edit the GET or POST data by intercepting the request, or change the query string after the response page loads. To test for HPP vulnerabilities simply append the same parameter to the GET or POST data but with a different value assigned.
A more in-depth analysis would require three HTTP requests for each HTTP parameter:
 Submit an HTTP request containing the standard parameter name and value, and record the HTTP response. E.g. page?par1=val1
 Replace the parameter value with a tampered value, submit and record the HTTP response. E.g. page?par1=HPP_TEST1
 Send a new request combining step (1) and (2). Again, save the HTTP response. E.g. page?par1=val1&par1=HPP_TEST1
 Compare the responses obtained during all previous steps. If the response from (3) is different from (1) and the response from (3) is also different from (2), there is an impedance mismatch that may be eventually abused to trigger HPP vulnerabilities.
2] Client-Side HPP
Similarly to server-side HPP, manual testing is the only reliable technique to audit web applications in order to detect parameter pollution vulnerabilities affecting client-side components. While in
the server-side variant the attacker leverages a vulnerable web application to access protected data or perform actions that either not permitted or not supposed to be executed, client-side attacks aim at subverting client-side components and technologies.
Similarly to server-side HPP, pollute each HTTP parameter with %26HPP_TEST and look for url-decoded occurrences of the user-supplied payload:
• … and others
In particular, pay attention to responses having HPP vectors with- in data, src, href attributes or forms actions. Again, whether or not this default behavior reveals a potential vulnerability depends on the
specific input validation, filtering and application business logic. In addition, it is important to notice that this vulnerability can also affect query string parameters used in XMLHttpRequest (XHR), runtime
attribute creation and other plugin technologies (e.g. Adobe Flash’s flashvars variables).
Twitter Unsubscribe Notifications
Report Link: merttasci.com/blog/twitter-hpp-vulnerability 2
Date Reported: August 23, 2015
Bounty Paid: $700
The risk posed by HTTP Parameter Pollution is really dependent on the actions performed by a site’s back end and where the polluted parameters are being submitted to.
Discovering these types of vulnerabilities really depends on experimentation, more so than other vulnerabilities because the back end actions of a website may be a complete black box to a hacker. More often than not, as a hacker, you will have very little insight into what actions a back end server takes after having received your input.
Through trial and error, you may be able to discover situations where a site is communicating with another server and then start testing for Parameter Pollution. Social media links are usually a good first step but remember to keep digging and think of HPP when you might be testing for parameter substitutions like UIDs.