Parameter Pollution | JSON Injection
Last updated
Last updated
Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
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 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.
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.
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.
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 das letzte Vorkommen 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 unbefugt auf private Daten zugreifen oder diese ändern.
Dieses Beispiel unterstreicht weiter die Notwendigkeit einer sicheren Parameterverarbeitung, insbesondere bei so kritischen Funktionen wie der Verwaltung von API-Schlüsseln.
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.
Die Ergebnisse stammen von https://medium.com/@0xAwali/http-parameter-pollution-in-2024-32ec1b810f89
Ignoriere alles nach %00 im Parameternamen.
Behandle name[] als Array.
_GET bedeutet nicht GET-Methode.
Bevorzuge den letzten Parameter.
Verwendet die & und ; Trennzeichen, um Parameter zu trennen.
name[] wird nicht erkannt.
Bevorzuge den ersten Parameter.
POST RequestMapping == PostMapping & GET RequestMapping == GetMapping.
POST RequestMapping & PostMapping erkennen name[].
Bevorzuge name, wenn name UND name[] vorhanden sind.
Verkette Parameter z.B. first,last.
POST RequestMapping & PostMapping erkennen Abfrageparameter mit Content-Type.
Erkennt name[].
Verkette Parameter z.B. first,last.
name[] wird NICHT erkannt.
Bevorzuge den ersten Parameter.
name[] wird NICHT erkannt.
Bevorzuge den ersten Parameter.
name[] wird NICHT erkannt.
Bevorzuge den letzten Parameter.
name[] wird NICHT erkannt.
Bevorzuge den letzten Parameter.
Der Frontend könnte die erste Vorkommen glauben, während das Backend die zweite Vorkommen des Schlüssels verwendet.
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:
Beachten Sie, wie in diesen Fällen das Frontend denken könnte, dass test == 1
und das Backend denken könnte, dass test == 2
.
Dies kann auch verwendet werden, um Wertbeschränkungen zu umgehen wie:
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:
Die GSON-Bibliothek von Java:
Ruby’s simdjson-Bibliothek:
Die Zahl
kann in mehrere Darstellungen decodiert werden, einschließlich:
Welche Inkonsistenzen erzeugen könnte
Lerne & übe AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Lerne & übe GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)