Parameter Pollution | JSON Injection

Parameter Pollution

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

1. Ignore anything after %00 in the parameter name .

2. Handle name[] as array .

3. _GET not meaning GET Method .

4. Prefer the last parameter .

Ruby 3.3.5 and WEBrick 1.8.2

1. Uses the & and ; delimiters to split parameters .

2. Not Recognized name[] .

3. Prefer the first parameter .

Spring MVC 6.0.23 AND Apache Tomcat 10.1.30

1. POST RequestMapping == PostMapping & GET RequestMapping == GetMapping .

2. POST RequestMapping & PostMapping Recognized name[] .

3. Prefer name if name AND name[] existing .

4. Concatenate parameters e.g. first,last .

5. POST RequestMapping & PostMapping Recognized query parameter with Content-Type .

NodeJS 20.17.0 AND Express 4.21.0

1. Recognized name[] .

2. Concatenate parameters e.g. first,last .

GO 1.22.7

1. NOT Recognized name[] .

2. Prefer the first parameter .

Python 3.12.6 AND Werkzeug 3.0.4 AND Flask 3.0.3

1. NOT Recognized name[] .

2. Prefer the first parameter .

Python 3.12.6 AND Django 4.2.15

1. NOT Recognized name[] .

2. Prefer the last parameter .

Python 3.12.6 AND Tornado 6.4.1

1. NOT Recognized name[] .

2. Prefer the last parameter .

JSON Injection

Duplicate keys

obj = {"test": "user", "test": "admin"}

The front-end might believe the first ocurrence while the backend uses the second ocurrence of the key.

Key Collision: Character Truncation and Comments

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:

{"test": 1, "test\[raw \x0d byte]": 2} 
{"test": 1, "test\ud800": 2}
{"test": 1, "test"": 2}
{"test": 1, "te\st": 2}

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:

{"role": "administrator\[raw \x0d byte]"} 
{"role":"administrator\ud800"}
{"role": "administrator""}
{"role": "admini\strator"}

Using Comment Truncation

obj = {"description": "Duplicate with comments", "test": 2, "extra": /*, "test": 1, "extra2": */}

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:

obj = {"description": "Comment support", "test": 1, "extra": "a"/*, "test": 2, "extra2": "b"*/}

Java’s GSON library:

{"description":"Comment support","test":1,"extra":"a"}

Ruby’s simdjson library:

{"description":"Comment support","test":2,"extra":"a","extra2":"b"}

Inconsistent Precedence: Deserialization vs. Serialization

obj = {"test": 1, "test": 2}

obj["test"] // 1
obj.toString() // {"test": 2}

Float and Integer

The number

999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999

can be decoded to multiple representations, including:

999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999
9.999999999999999e95
1E+96
0
9223372036854775807

Which might create inconsistences

References

• https://medium.com/@shahjerry33/http-parameter-pollution-its-contaminated-85edc0805654

• https://github.com/google/google-ctf/tree/master/2023/web-under-construction/solution

• https://medium.com/@0xAwali/http-parameter-pollution-in-2024-32ec1b810f89

• https://bishopfox.com/blog/json-interoperability-vulnerabilities