Difference between revisions of "Testing for HTTP Parameter pollution (OTG-INPVAL-004)"

Revision as of 15:19, 22 August 2013

This article is part of the new OWASP Testing Guide v4.

Back to the OWASP Testing Guide v4 ToC:
   https://www.owasp.org/index.php/OWASP_Testing_Guide_v4_Table_of_Contents
Back to the OWASP Testing Guide Project:
   https://www.owasp.org/index.php/OWASP_Testing_Project

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: "select 1,2,3 from table." The filter would block this example URL from being processed by the web server: /index.aspx?page=select 1,2,3 from table.

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 /index.aspx?page=select 1&page=2,3 from table 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: http://example.com/?color=red&color=blue

(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 search_string parameter in the query string, the request URL would include that parameter name and value.
http://example.com/?search_string=kittens
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.
http://example.com/?mode=guest&search_string=kittens&num_results=100
Append the same parameter with a different value
http://example.com/?mode=guest&search_string=kittens&num_results=100&search_string=puppies
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 kittens, puppies, some combination of both (kittens,puppies or kittens~puppies 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.
Crafting a full exploit from a parameter pollution weakness is beyond the scope of this test. See the references for examples and details.

References

Whitepapers
HTTP Parameter Pollution - Luca Carettoni, Stefano di Paola - https://www.owasp.org/images/b/ba/AppsecEU09_CarettoniDiPaola_v0.8.pdf

How to Detect HTTP Parameter Pollution Attacks - Chrysostomos Daniel, Acutenix - http://www.acunetix.com/blog/whitepaper-http-parameter-pollution/

CAPEC-460: HTTP Parameter Pollution (HPP) - Evgeny Lebanidze, Cigital - http://capec.mitre.org/data/definitions/460.html

Tools
...