Parameter Pollution | JSON Injection
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
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.
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.
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.
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.
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.
There results were taken from https://medium.com/@0xAwali/http-parameter-pollution-in-2024-32ec1b810f89
Ignore anything after %00 in the parameter name .
Handle name[] as array .
_GET not meaning GET Method .
Prefer the last parameter .
Uses the & and ; delimiters to split parameters .
Not Recognized name[] .
Prefer the first parameter .
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 .
Recognized name[] .
Concatenate parameters e.g. first,last .
NOT Recognized name[] .
Prefer the first parameter .
NOT Recognized name[] .
Prefer the first parameter .
NOT Recognized name[] .
Prefer the last parameter .
NOT Recognized name[] .
Prefer the last parameter .
The front-end might believe the first ocurrence while the backend uses the second ocurrence of the key.
Certain characters aren't going to be correctly interpreted by the frontend but the backend will interpret them and use those keys, this could be useful to bypass certain restrictions:
Note how in these cases the front end might think that test == 1 and the backend will think that test == 2.
This can also by used to bypass value restrictions like:
Here we will use the serializer from each parser to view its respective output.
Serializer 1 (e.g., GoLang's GoJay library) will produce:
description = "Duplicate with comments"
test = 2
extra = ""
Serializer 2 (e.g., Java's JSON-iterator library) will produce:
description = "Duplicate with comments"
extra = "/*"
extra2 = "*/"
test = 1
Alternatively, straightforward use of comments can also be effective:
Java’s GSON library:
Ruby’s simdjson library:
The number
can be decoded to multiple representations, including:
Which might create inconsistences
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
