Parameter Pollution

{% hint style="success" %} Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

Check the subscription plans!
Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.
Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.

{% endhint %}

{% embed url="https://websec.nl/" %}

HTTP Parameter Pollution (HPP) Overview

HTTP Parameter Pollution (HPP) is a technique where attackers manipulate HTTP parameters to change the behavior of a web application in unintended ways. This manipulation is done by adding, modifying, or duplicating HTTP parameters. The effect of these manipulations is not directly visible to the user but can significantly alter the application's functionality on the server side, with observable impacts on the client side.

Example of HTTP Parameter Pollution (HPP)

A banking application transaction URL:

Original URL: https://www.victim.com/send/?from=accountA&to=accountB&amount=10000

By inserting an additional from parameter:

Manipulated URL: https://www.victim.com/send/?from=accountA&to=accountB&amount=10000&from=accountC

The transaction may be incorrectly charged to accountC instead of accountA, showcasing the potential of HPP to manipulate transactions or other functionalities such as password resets, 2FA settings, or API key requests.

Technology-Specific Parameter Parsing

The way parameters are parsed and prioritized depends on the underlying web technology, affecting how HPP can be exploited.
Tools like Wappalyzer help identify these technologies and their parsing behaviors.

PHP and HPP Exploitation

OTP Manipulation Case:

Context: A login mechanism requiring a One-Time Password (OTP) was exploited.
Method: By intercepting the OTP request using tools like Burp Suite, attackers duplicated the email parameter in the HTTP request.
Outcome: The OTP, meant for the initial email, was instead sent to the second email address specified in the manipulated request. This flaw allowed unauthorized access by circumventing the intended security measure.

This scenario highlights a critical oversight in the application's backend, which processed the first email parameter for OTP generation but used the last for delivery.

API Key Manipulation Case:

Scenario: An application allows users to update their API key through a profile settings page.
Attack Vector: An attacker discovers that by appending an additional api_key parameter to the POST request, they can manipulate the outcome of the API key update function.
Technique: Utilizing a tool like Burp Suite, the attacker crafts a request that includes two api_key parameters: one legitimate and one malicious. The server, processing only the last occurrence, updates the API key to the attacker's provided value.
Result: The attacker gains control over the victim's API functionality, potentially accessing or modifying private data unauthorizedly.

This example further underscores the necessity for secure parameter handling, especially in features as critical as API key management.

Parameter Parsing: Flask vs. PHP

The way web technologies handle duplicate HTTP parameters varies, affecting their susceptibility to HPP attacks:

Flask: Adopts the first parameter value encountered, such as a=1 in a query string a=1&a=2, prioritizing the initial instance over subsequent duplicates.
PHP (on Apache HTTP Server): Contrarily, prioritizes the last parameter value, opting for a=2 in the given example. This behavior can inadvertently facilitate HPP exploits by honoring the attacker's manipulated parameter over the original.

Parameter pollution by technology

There results were taken from https://medium.com/@0xAwali/http-parameter-pollution-in-2024-32ec1b810f89

PHP 8.3.11 AND Apache 2.4.62

https://miro.medium.com/v2/resize:fit:1100/format:webp/1*l_Pf2JNCYhmfAvfk7UTEbQ.jpeg

Ignore anything after %00 in the parameter name .
Handle name[] as array .
_GET not meaning GET Method .
Prefer the last parameter .

Ruby 3.3.5 and WEBrick 1.8.2

https://miro.medium.com/v2/resize:fit:1100/format:webp/1*kKxtZ8qEmgTIMS81py5hhg.jpeg

Uses the & and ; delimiters to split parameters .
Not Recognized name[] .
Prefer the first parameter .

Spring MVC 6.0.23 AND Apache Tomcat 10.1.30

https://miro.medium.com/v2/resize:fit:1100/format:webp/1*llG22MF1gPTYZYFVCmCiVw.jpeg

POST RequestMapping == PostMapping & GET RequestMapping == GetMapping .
POST RequestMapping & PostMapping Recognized name[] .
Prefer name if name AND name[] existing .
Concatenate parameters e.g. first,last .
POST RequestMapping & PostMapping Recognized query parameter with Content-Type .