HTTP allows multiple parameters with the same name, both in the GET and POST methods. The HTTP standards neither explain nor have rules set on how to interpret multiple input parameters with the same name—whether to accept the last occurrence of the variable or the first occurrence, or to use the variable as an array.
For example, the following POST request is per the standard, even when the item_id variable has num1 and num2 as values:
item_id=num1&second_parameter=3&item_id=num2
Although it is acceptable per HTTP protocol standard, the way that different web servers and development frameworks handle multiple parameters varies. The unknown process of handling multiple parameters often leads to security issues. This unexpected behavior is known as HTTP parameter pollution. The following table shows HTTP duplicated parameter behavior in major web servers:
Framework/Web server |
Resulting action |
Example |
ASP.NET/IIS |
All occurrences concatenated with a comma |
item_id=num1,num2 |
PHP/Apache |
Last occurrence |
item_id=num2 |
JSP/Tomcat |
First occurrence |
item_id=num1 |
IBM HTTP server |
First occurrence |
item_id=num1 |
Python |
All occurrences combined in a list (array) |
item_id=['num1','num2'] |
Perl /Apache |
First occurrence |
item_id=num1 |
Imagine a scenario where a Tomcat server is behind Web Application Firewall (WAF) whose code is based on Apache and PHP, and an attacker sends the following parameter list in a request:
item_id=num1'+or+'1'='1&second_parameter=3&item_id=num2
WAF will take the last occurrence of the parameter and determine that it is a legitimate value, while the web server will take the first one, and, if the application is vulnerable to SQL injection, the attack will succeed, bypassing the protection provided by WAF.