Parameter Tampering

Pourquoi c'est important

L'essentiel du travail sensible d'une application se déroule dans des paramètres que l'utilisateur ne voit jamais dans la barre d'adresse. Les corps POST et PUT transportent des identifiants, des drapeaux, des clés d'API et des noms d'action, et comme ils n'apparaissent pas dans l'URL, les développeurs les valident souvent moins strictement. C'est précisément dans cet écart que le parameter tampering trouve des bugs.

Le tampering est rarement un bug unique. C'est une sonde. Une seule valeur modifiée peut révéler une divulgation d'information, une injection SQL, un IDOR ou une vulnérabilité de logique métier, ce qui en fait l'une des habitudes à plus forte valeur qu'un testeur puisse développer. Il ne demande non plus aucun outillage particulier au-delà d'un proxy d'interception comme Burp Suite, ce qui en fait l'une des premières compétences qu'un débutant peut transformer en découvertes réelles.

Où vivent les paramètres

Une application envoie des paramètres au serveur à plusieurs endroits, et chacun est éditable avec un proxy :

• Chaîne de requête de l'URL : ?page=1&sort=price, visible dans la barre d'adresse.
• Corps POST et PUT : valeurs encodées en formulaire ou en JSON, masquées de l'URL et souvent validées de façon laxiste.
• Cookies et en-têtes : état de session, rôles, drapeaux de fonctionnalité et indices d'IP, tous contrôlés par l'attaquant.

Comment ça fonctionne

Le testeur capture une requête, change un paramètre à la fois, la renvoie et lit la réponse brute. La discipline consiste à ne changer qu'une seule chose par requête afin que la cause de tout changement de comportement soit sans ambiguïté. Les sondes diffèrent selon le type de donnée :

• Valeurs numériques : essayez une apostrophe, un nombre négatif, un zéro, un très grand nombre et l'identifiant d'un autre utilisateur. Une apostrophe qui produit une erreur de base de données pointe vers une injection SQL ; les données d'un autre utilisateur qui reviennent pointent vers un IDOR.
• Drapeaux booléens : inversez isAdmin=false en true, verified=no en yes, ou supprimez entièrement le paramètre pour voir si le serveur retombe sur une valeur par défaut non sécurisée.
• Champs de prix et de quantité : abaissez un prix, fixez une quantité négative, ou changez une devise pour tester la logique de paiement.
• Chaînes de caractères : essayez des apostrophes, des barres obliques inverses, des octets nuls et des séquences de traversée de répertoire telles que ../../etc/passwd.

Impact dans le monde réel

Le parameter tampering a produit de tout, depuis des achats gratuits via un champ price manipulé, jusqu'à la prise de contrôle de compte via un identifiant d'utilisateur substitué, en passant par l'extraction complète d'une base de données qui a débuté avec une seule apostrophe dans un paramètre numérique. Parce qu'il cible la confiance plutôt qu'une technologie précise, il apparaît aussi bien dans les applications web classiques, les applications monopages modernes que dans les API.

Prévention

Traitez chaque paramètre comme hostile. Utilisez des requêtes paramétrées pour empêcher l'injection, imposez une autorisation au niveau de l'objet sur chaque référence, recalculez les prix et les totaux côté serveur, et rejetez les champs inattendus plutôt que de les lier automatiquement. Lorsqu'une valeur doit survivre à un aller-retour par le client, signez-la ou chiffrez-la pour que le tampering soit détectable, et journalisez les anomalies comme les prix négatifs ou les accès qui franchissent les frontières entre utilisateurs.