Testing for HTTP Parameter pollution (OTG-INPVAL-004)

Brief Summary
Supplying multiple HTTP parameters with the same name may cause an application to interpret values in unanticipated ways. By exploiting these effects, an attacker may be able to bypass input validation, trigger application errors, or modify internal variables values.

Description of the Issue
Current HTTP standards do not include guidance on how to interpret multiple input parameters with the same name. Without a standard in place, web applications handle this edge case in a variety of ways (see the table below for details). It is not necessarily an indication of vulnerability when an application server responds to multiple similar parameters; this is expected behavior for handling an unusual input. The vulnerability depends if an one can abuse the concatenation or substitution of variable values to cause errors or bypass validation.

For example, when HTTP Parameter Pollution was first identified, a flaw was identified using the ModSecurity SQL Injection filter. The ModSecurity filter would correctly blacklist the following string: " ." The filter would block this example URL from being processed by the web server:.

However, by exploiting the concatenation of multiple HTTP parameters, an attacker could cause the application server to concatenate the string after the ModSecurity filter already accepted the input. As an example, the URL  would not trigger the ModSecurity filter, yet the application layer would concatenate the input back into the full malicious string.

Expected Behavior by Application Server
Given the URL and querystring: (source: [[Media:AppsecEU09_CarettoniDiPaola_v0.8.pdf]] )

Black Box testing and example
Luckily, because the assignment of HTTP parameters is typically handled via the web application server, and not the application code itself, testing the response to parameter pollution should be standard across all pages and actions. To test for vulnerability, identify any form or action that allows user input and shows a result of that input back to the user. A search page is ideal, but a login box might not work (as it might not show an invalid username back to the user). Query string parameters are easy to tweak in the navigation bar itself. 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, go ahead and submit input via the HTML form or action. One can edit the GET or POST data by intercepting the request, or change the query string after the response page loads. Find the parameter being tested, and simply append the same parameter to the GET or POST data but with a different value assigned. For example: if testing the  parameter in the query string, the request URL would include that parameter name and value. The particular parameter might be hidden among several other parameters, but the approach is the same; leave the other parameters in place and append the duplicate. Append the same parameter with a different value and submit the new request. Analyze the response page to determine which value(s) were parsed. In the above example, the search results may show,  , some combination of both (  or   or ['kittens','puppies']), may give an empty result, or error page. This behavior, whether using the first, last, or combination of input parameters with the same name, is very likely to be consistent across the entire application. Whether or not this default behavior reveals a potential vulnerability depends on the specific input validation and filtering specific to a particular application. As a general rule: if existing input validation methods are sufficient on single inputs, and if the server assigns only the first or last polluted parameters, then parameter pollution does not reveal a vulnerability. If the duplicate parameters are concatenated or generate an error, there is an increased likelihood of being able to use parameter pollution to bypass regular input validation.