Parameter Pollution | JSON Injection

Reading time: 8 minutes

Parameter Pollution

HTTP Parameter Pollution (HPP) Übersicht

HTTP Parameter Pollution (HPP) ist eine Technik, bei der Angreifer HTTP-Parameter manipulieren, um das Verhalten einer Webanwendung auf unbeabsichtigte Weise zu ändern. Diese Manipulation erfolgt durch das Hinzufügen, Ändern oder Duplizieren von HTTP-Parametern. Die Auswirkungen dieser Manipulationen sind für den Benutzer nicht direkt sichtbar, können jedoch die Funktionalität der Anwendung auf der Serverseite erheblich verändern, mit beobachtbaren Auswirkungen auf der Clientseite.

Beispiel für HTTP Parameter Pollution (HPP)

Eine Transaktions-URL einer Banking-Anwendung:

• Ursprüngliche URL: https://www.victim.com/send/?from=accountA&to=accountB&amount=10000

Durch das Einfügen eines zusätzlichen from-Parameters:

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

Die Transaktion könnte fälschlicherweise accountC anstelle von accountA belastet werden, was das Potenzial von HPP zur Manipulation von Transaktionen oder anderen Funktionen wie Passwortzurücksetzungen, 2FA-Einstellungen oder API-Schlüsselanforderungen zeigt.

Technologiespezifische Parameterverarbeitung

• Die Art und Weise, wie Parameter verarbeitet und priorisiert werden, hängt von der zugrunde liegenden Webtechnologie ab, was die Ausnutzbarkeit von HPP beeinflusst.
• Tools wie Wappalyzer helfen dabei, diese Technologien und deren Verhaltensweisen bei der Verarbeitung zu identifizieren.

PHP und HPP-Ausnutzung

OTP-Manipulationsfall:

• Kontext: Ein Anmeldeverfahren, das ein Einmalpasswort (OTP) erfordert, wurde ausgenutzt.
• Methode: Durch das Abfangen der OTP-Anforderung mit Tools wie Burp Suite duplizierten Angreifer den email-Parameter in der HTTP-Anforderung.
• Ergebnis: Das OTP, das für die ursprüngliche E-Mail bestimmt war, wurde stattdessen an die zweite in der manipulierten Anfrage angegebene E-Mail-Adresse gesendet. Dieser Fehler ermöglichte unbefugten Zugriff, indem die beabsichtigte Sicherheitsmaßnahme umgangen wurde.

Dieses Szenario hebt einen kritischen Fehler im Backend der Anwendung hervor, das den ersten email-Parameter zur OTP-Generierung verarbeitete, aber den letzten für die Zustellung verwendete.

API-Schlüssel-Manipulationsfall:

• Szenario: Eine Anwendung ermöglicht es Benutzern, ihren API-Schlüssel über eine Profilseite zu aktualisieren.
• Angriffsvektor: Ein Angreifer entdeckt, dass er durch das Anhängen eines zusätzlichen api_key-Parameters an die POST-Anforderung das Ergebnis der API-Schlüsselaktualisierungsfunktion manipulieren kann.
• Technik: Mit einem Tool wie Burp Suite erstellt der Angreifer eine Anfrage, die zwei api_key-Parameter enthält: einen legitimen und einen bösartigen. Der Server, der nur die letzte Instanz verarbeitet, aktualisiert den API-Schlüssel auf den vom Angreifer bereitgestellten Wert.
• Ergebnis: Der Angreifer erhält die Kontrolle über die API-Funktionalität des Opfers und kann möglicherweise private Daten unbefugt abrufen oder ändern.

Dieses Beispiel unterstreicht weiter die Notwendigkeit einer sicheren Parameterverarbeitung, insbesondere bei so kritischen Funktionen wie der Verwaltung von API-Schlüsseln.

Parameterverarbeitung: Flask vs. PHP

Die Art und Weise, wie Webtechnologien doppelte HTTP-Parameter behandeln, variiert und beeinflusst ihre Anfälligkeit für HPP-Angriffe:

• Flask: Nimmt den ersten gefundenen Parameterwert an, wie a=1 in einer Abfragezeichenfolge a=1&a=2, und priorisiert die erste Instanz gegenüber nachfolgenden Duplikaten.
• PHP (auf Apache HTTP Server): Priorisiert hingegen den letzten Parameterwert und wählt a=2 im gegebenen Beispiel. Dieses Verhalten kann unbeabsichtigt HPP-Angriffe erleichtern, indem es den manipulierten Parameter des Angreifers über den ursprünglichen anerkennt.

Parameterverunreinigung nach Technologie

Die Ergebnisse stammen von https://medium.com/@0xAwali/http-parameter-pollution-in-2024-32ec1b810f89

PHP 8.3.11 UND Apache 2.4.62

1. Ignoriere alles nach %00 im Parameternamen.
2. Behandle name[] als Array.
3. _GET bedeutet nicht GET-Methode.
4. Bevorzuge den letzten Parameter.

Ruby 3.3.5 und WEBrick 1.8.2

1. Verwendet die & und ; Trennzeichen, um Parameter zu trennen.
2. name[] wird nicht erkannt.
3. Bevorzuge den ersten Parameter.

Spring MVC 6.0.23 UND Apache Tomcat 10.1.30

1. POST RequestMapping == PostMapping & GET RequestMapping == GetMapping.
2. POST RequestMapping & PostMapping erkennen name[].
3. Bevorzuge name, wenn name UND name[] vorhanden sind.
4. Verkette Parameter, z.B. first,last.
5. POST RequestMapping & PostMapping erkennen Abfrageparameter mit Content-Type.

NodeJS 20.17.0 UND Express 4.21.0

1. Erkennt name[].
2. Verkette Parameter, z.B. first,last.

GO 1.22.7

1. name[] wird nicht erkannt.
2. Bevorzuge den ersten Parameter.

Python 3.12.6 UND Werkzeug 3.0.4 UND Flask 3.0.3

1. name[] wird nicht erkannt.
2. Bevorzuge den ersten Parameter.

Python 3.12.6 UND Django 4.2.15

1. name[] wird nicht erkannt.
2. Bevorzuge den letzten Parameter.

Python 3.12.6 UND Tornado 6.4.1

1. name[] wird nicht erkannt.
2. Bevorzuge den letzten Parameter.

JSON Injection

Doppelte Schlüssel

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

Die Front-End-Anwendung könnte die erste Vorkommen glauben, während das Backend das zweite Vorkommen des Schlüssels verwendet.

Schlüsselkonkurrenz: Zeichenabschneidung und Kommentare

Bestimmte Zeichen werden vom Frontend möglicherweise nicht korrekt interpretiert, aber das Backend wird sie interpretieren und diese Schlüssel verwenden. Dies könnte nützlich sein, um bestimmte Einschränkungen zu umgehen:

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

Beachten Sie, dass in diesen Fällen das Frontend denken könnte, dass test == 1 und das Backend denken wird, dass test == 2.

Dies kann auch verwendet werden, um Wertbeschränkungen zu umgehen wie:

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

Verwendung von Kommentartruncation

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

Hier verwenden wir den Serializer von jedem Parser, um dessen jeweilige Ausgabe zu sehen.

Serializer 1 (z.B. GoLangs GoJay-Bibliothek) produziert:

• description = "Duplicate with comments"
• test = 2
• extra = ""

Serializer 2 (z.B. Javas JSON-iterator-Bibliothek) produziert:

• description = "Duplicate with comments"
• extra = "/*"
• extra2 = "*/"
• test = 1

Alternativ kann die einfache Verwendung von Kommentaren ebenfalls effektiv sein:

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

Die GSON-Bibliothek von Java:

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

Ruby’s simdjson-Bibliothek:

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

Inkonsistente Priorität: Deserialisierung vs. Serialisierung

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

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

Float und Integer

Die Zahl

999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999

kann in mehrere Darstellungen decodiert werden, einschließlich:

999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999
9.999999999999999e95
1E+96
0
9223372036854775807

Die möglicherweise Inkonsistenzen erzeugen könnten

Referenzen

• 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