HTTP Parameter Pollution (HPP)
HTTP Parameter Pollution exploits the ability to include multiple parameters with the same name in an HTTP request. Depending on the web application, these parameters will be parsed in different ways (i.e. only parsing the first/last occurrence of the parameter or concatenating all occurrences into one field or array). This can create unexpected behaviour on both the client and server side of the application.
Attack Vector
In an HPP attack, the attacker first needs to research how exactly the web application handles parsing HTTP parameter inputs. With this information, the attacker can modify an HTTP request typically expected by the web application by adding extra parameters with the same name as those in the original request, but with unexpected values.
In a client-side attack, the request is then placed so that another user will interact with it, such as by sending a url to the victim for them to click on.
In a server-side attack, the attacker injects the HTTP request in a place on the web application where they see a possible vulnerability to exploit, such as interacting with a database.
Impact
The impact of an HTTP Parameter Pollution attack depends on the functionality of the web application and which part is targeted. This attack accomplishes different outcomes such as overwriting the actions of hard coded HTTP parameters, accessing uncontrolled variables and therefore possibly exploiting them, bypassing web application firewalls (WAFs) or input validation checks, and changing behaviors of the application.
Attack Examples
Example 1 - Client-side
Eve was not invited to Bob's birthday party and she is not happy about
it. She knows, however, that Bob invited Alice with an online
invitation at the link
bobsbday.com/invite.php?friend=Alice&action=sendinvite.
Eve knows that bobsbday.com, when given multiple parameters of the
same name, only takes the last parameter. So she decides to use an HPP
attack and creates this new link to send to Alice
bobsbday.com/invite.php?friend=Alice&action=sendinvite%26friend=Eve
(%26 is the encoding of &). When Alice clicks on the link, it is
evaluated into
bobsbday.com/invite.php?friend=Alice&action=sendinvite&friend=Eve
resulting in the invitation being sent to Eve rather than Alice.
Example 2 - Server-side
bank.com stores all of its past transactions in a database accessible
at the url bank.com/history?page=1. Eve wants to see Bob's past
transactions because he owes her some money. She knows that bank.com
will concatenate all HTTP parameter values of the same parameter name
into one value separated by commas, so she uses an HPP attack to
perform SQL injection. She inputs the url
bank.com/history?page=select receiverpage=amount from transactions
where sender=Bob. Since the sql statement is split into two inputs,
no alarms are raised when validating the input by the system, however
it is still evaluated as "select receiver, amount from transactions
where sender = Bob". This then displays all of Bob's transactions to
Eve.
Defenses
To defend against HPP attacks, a thorough sanitization and validation of HTTP requests must be performed before executing the request. This requires specific knowledge of the application itself and how it handles parsing HTTP parameters.
Criteria for Demonstration
To demonstrate an HPP attack, provide the exact HTTP request with parameters you added and where this request is used on the flag website. Show how these added parameters led to unexpected behavior.
Other resources
https://www.acunetix.com/blog/whitepaper-http-parameter-pollution/
https://owasp.org/www-pdf-archive/AppsecEU09_CarettoniDiPaola_v0.8.pdf
https://medium.com/@onehackman/http-parameter-pollution-english-90fd5eec7a3b
srowley2