Parameter Pollution | JSON Injection

Tip

Apprenez et pratiquez le hacking AWS :HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez le hacking GCP : HackTricks Training GCP Red Team Expert (GRTE) Apprenez et pratiquez le hacking Azure : HackTricks Training Azure Red Team Expert (AzRTE)

Soutenir HackTricks

HTTP Parameter Pollution (HPP) — Aperçu

HTTP Parameter Pollution (HPP) est une technique où des attaquants manipulent les paramètres HTTP pour modifier le comportement d’une application web de manière non intentionnelle. Cette manipulation se fait en ajoutant, modifiant ou dupliquant des paramètres HTTP. L’effet de ces manipulations n’est pas directement visible par l’utilisateur mais peut altérer significativement le fonctionnement de l’application côté serveur, avec des impacts observables côté client.

Exemple de HTTP Parameter Pollution (HPP)

Une URL de transaction d’une application bancaire :

  • URL d’origine : https://www.victim.com/send/?from=accountA&to=accountB&amount=10000

En insérant un paramètre from supplémentaire :

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

La transaction peut être débitée incorrectement du compte accountC au lieu de accountA, montrant le potentiel du HPP pour manipuler des transactions ou d’autres fonctionnalités telles que les réinitialisations de mot de passe, les paramètres 2FA, ou les demandes de API key.

Analyse des paramètres spécifique à la technologie

  • La façon dont les paramètres sont parsés et priorisés dépend de la technologie web sous-jacente, ce qui affecte la manière dont le HPP peut être exploité.
  • Des outils comme Wappalyzer aident à identifier ces technologies et leurs comportements de parsing.

Exploitation PHP et HPP

Cas — Manipulation OTP :

  • Contexte : Un mécanisme de connexion nécessitant un One-Time Password (OTP) a été exploité.
  • Méthode : En interceptant la requête d’OTP avec des outils comme Burp Suite, les attaquants ont dupliqué le paramètre email dans la requête HTTP.
  • Résultat : L’OTP, destiné à l’email initial, a été envoyé à la seconde adresse email spécifiée dans la requête manipulée. Cette faille a permis un accès non autorisé en contournant la mesure de sécurité prévue.

Ce scénario met en évidence une erreur critique dans le backend de l’application, qui utilisait le premier paramètre email pour la génération de l’OTP mais le dernier pour la livraison.

Cas — Manipulation API key :

  • Scénario : Une application permet aux utilisateurs de mettre à jour leur API key via une page de paramètres de profil.
  • Vecteur d’attaque : Un attaquant découvre qu’en ajoutant un paramètre api_key supplémentaire à la requête POST, il peut manipuler le résultat de la fonction de mise à jour de l’API key.
  • Technique : En utilisant un outil comme Burp Suite, l’attaquant construit une requête contenant deux paramètres api_key : un légitime et un malveillant. Le serveur, traitant uniquement la dernière occurrence, met à jour l’API key avec la valeur fournie par l’attaquant.
  • Résultat : L’attaquant prend le contrôle de la fonctionnalité API du victim, pouvant potentiellement accéder ou modifier des données privées de manière non autorisée.

Cet exemple souligne encore la nécessité d’un traitement sécurisé des paramètres, surtout pour des fonctionnalités critiques comme la gestion des API key.

Interprétation des paramètres : Flask vs. PHP

La manière dont les technologies web gèrent les paramètres HTTP dupliqués varie, affectant leur vulnérabilité aux attaques HPP :

  • Flask : Prend la première valeur de paramètre rencontrée, par exemple a=1 dans une query string a=1&a=2, en priorisant l’instance initiale plutôt que les duplicata.
  • PHP (sur Apache HTTP Server) : Au contraire, priorise la dernière valeur de paramètre, optant pour a=2 dans l’exemple donné. Ce comportement peut faciliter involontairement les exploits HPP en honorant le paramètre manipulé par l’attaquant plutôt que l’original.

Notes de test HPP (OWASP WSTG)

  • Les standards HTTP ne définissent pas comment interpréter plusieurs paramètres portant le même nom, donc le comportement varie selon les stacks et les composants.
  • Lors du test du HPP côté serveur, dupliquez chaque paramètre dans les query strings ou les bodies et observez si l’application concatène les valeurs, utilise la première/dernière, ou génère une erreur.
  • Pour le HPP côté client, injectez un & encodé pour URL dans une valeur de paramètre reflétée (par ex. %26HPP_TEST) et recherchez des occurrences décodées comme &HPP_TEST ou &HPP_TEST à l’intérieur des liens générés ou des actions de formulaires.

Server-Side Parameter Pollution (SSPP) dans les API internes

Certaines applications intègrent l’entrée utilisateur dans des requêtes côté serveur vers des API internes. Si cette entrée n’est pas correctement encodée, vous pouvez injecter ou écraser des paramètres dans la requête interne. Testez toute entrée utilisateur, y compris les query parameters, les champs de formulaire, les headers et les paramètres de chemin d’URL.

Sondes courantes :

  • Ajoutez un nouveau paramètre avec %26 (URL-encoded &).
  • Tronquez la query en aval avec %23 (URL-encoded #).
  • Écrasez un paramètre existant en le dupliquant.

Exemple :

GET /userSearch?name=peter%26name=carlos&back=/home

Peut entraîner une requête côté serveur telle que:

GET /users/search?name=peter&name=carlos&publicProfile=true

Parameter pollution by technology

Ces résultats proviennent de https://medium.com/@0xAwali/http-parameter-pollution-in-2024-32ec1b810f89

PHP 8.3.11 ET Apache 2.4.62

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

  1. Ignorer tout ce qui suit %00 dans le nom du paramètre.
  2. Traiter name[] comme un tableau.
  3. _GET ne signifie pas la méthode GET.
  4. Privilégier le dernier paramètre.

Ruby 3.3.5 ET WEBrick 1.8.2

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

  1. Utiliser les délimiteurs & et ; pour séparer les paramètres.
  2. Ne reconnaît pas name[].
  3. Privilégier le premier paramètre.

Spring MVC 6.0.23 ET Apache Tomcat 10.1.30

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

  1. POST RequestMapping == PostMapping & GET RequestMapping == GetMapping.
  2. POST RequestMapping et PostMapping reconnaissent name[].
  3. Préférer name si name et name[] existent.
  4. Concaténer les paramètres, p. ex. first,last.
  5. POST RequestMapping et PostMapping reconnaissent les paramètres de requête avec Content-Type.

NodeJS 20.17.0 ET Express 4.21.0

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

  1. Reconnaît name[].
  2. Concaténer les paramètres, p. ex. first,last.

GO 1.22.7

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

  1. Ne reconnaît pas name[].
  2. Privilégier le premier paramètre.

Python 3.12.6 ET Werkzeug 3.0.4 ET Flask 3.0.3

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

  1. Ne reconnaît pas name[].
  2. Privilégier le premier paramètre.

Python 3.12.6 ET Django 4.2.15

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

  1. Ne reconnaît pas name[].
  2. Privilégier le dernier paramètre.

Python 3.12.6 ET Tornado 6.4.1

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

  1. Ne reconnaît pas name[].
  2. Privilégier le dernier paramètre.

JSON Injection

JSON, XML and YAML Hacking

Clés dupliquées

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

Le front-end pourrait croire la première occurrence tandis que le backend utilise la deuxième occurrence de la clé.

Key Collision: Character Truncation and Comments

Certains caractères ne vont pas être correctement interprétés par le frontend mais le backend les interprétera et utilisera ces clés, cela pourrait être utile pour bypass certaines restrictions:

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

Remarquez comment, dans ces cas, le front end pourrait croire que test == 1 et le backend croira que test == 2.

Cela peut également être utilisé pour contourner des restrictions de valeur comme :

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

Utilisation de Comment Truncation

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

Ici nous utiliserons le serializer de chaque parser pour afficher sa sortie respective.

Serializer 1 (e.g., GoLang’s GoJay library) produira :

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

Serializer 2 (e.g., Java’s JSON-iterator library) produira :

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

Alternativement, l’utilisation simple de commentaires peut aussi être efficace :

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

La bibliothèque GSON de Java :

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

La bibliothèque simdjson de Ruby :

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

Précédence Incohérente : Deserialization vs. Serialization

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

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

Float et entier

Le nombre

999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999

peut être décodé en plusieurs représentations, y compris :

999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999
9.999999999999999e95
1E+96
0
9223372036854775807

Ce qui pourrait créer des incohérences

Références

Tip

Apprenez et pratiquez le hacking AWS :HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez le hacking GCP : HackTricks Training GCP Red Team Expert (GRTE) Apprenez et pratiquez le hacking Azure : HackTricks Training Azure Red Team Expert (AzRTE)

Soutenir HackTricks