Difference between revisions of "Testing for HTTP Parameter pollution (OWASP-DV-004)"
|Line 13:||Line 13:|
For example, when using the
For example, when using the the ,
multiple parameters. , the codestring.
Revision as of 12:08, 21 August 2013
This article is part of the new OWASP Testing Guide v4.
At the moment the project is in the REVIEW phase.
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: http://www.owasp.org/index.php/OWASP_Testing_Project
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 at the application layer, be concatenated back into the full blacklisted string.
Given the URL and querystring:
|Web Application Server Backend||Parsing Result||Example|
|ASP.NET / IIS||All occurrences concatenated with a comma||color=red,blue|
|ASP / IIS||All occurrences concatenated with a comma||color=red,blue|
|PHP / Apache||Last occurrence only||color=blue|
|PHP / Zeus||Last occurrence only||color=blue|
|JSP, Servlet / Apache Tomcat||First occurrence only||color=red|
|JSP, Servlet / Oracle Application Server 10g||First occurrence only||color=red|
|JSP, Servlet / Jetty||First occurrence only||color=red|
|IBM Lotus Domino||Last occurrence only||color=blue|
|IBM HTTP Server||First occurrence only||color=red|
|mod_perl, libapreq2 / Apache||First occurrence only||color=red|
|Perl CGI / Apache||First occurrence only||color=red|
|mod_wsgi (Python) / Apache||First occurrence only||color=red|
|Python / Zope||All occurrences in List data type||color=['red','blue']|
(source: Media:AppsecEU09_CarettoniDiPaola_v0.8.pdf )
Black Box testing and example
Testing for Topic X vulnerabilities: