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.
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. As HTTP Parameter Pollution (in short HPP) affects a building block of all web technologies, server and client side attacks exist.
By itself, this is not necessarily an indication of vulnerability. However, if the developer is not aware of the problem, the presence of duplicated parameters may produce an anomalous behavior in the application that can be potentially exploited by an attacker. As often in security, unexpected behaviors are a usual source of weaknesses that could lead to HTTP Parameter Pollution attacks in this case.
An even more critical HPP vulnerability was discovered in Blogger, the popular blogging platform. The bug allowed malicious users to take ownership of the victim’s blog by using the following HTTP request:
POST /add-authors.do HTTP/1.1
The flaw resided in the authentication mechanism used by the web application, as the security check was performed on the first
blogID parameter, whereas the actual operation used the second occurrence.
Expected Behavior by Application Server
The following table is a defined example of OWASP that illustrates how different web technologies behave in presence of multiple occurrences of the same HTTP parameter.
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’]|
Explanation with detailed example:
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
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 HPP 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
<? $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 as described above in OWASP example.
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.