Qu’est-ce que la contamination des paramètres HTTP et pourquoi représente-t-elle un risque réel ?

Quand on parle de sécurité des applications web, beaucoup de gens ne pensent qu'à… Injection SQL, XSS ou échecs d'authentificationCependant, depuis des années, une technique plutôt discrète passe inaperçue dans de nombreux audits : la contamination ou la pollution des paramètres HTTP, connue sous le nom de Pollution des paramètres HTTP (HPP) o Contamination des paramètres HTTP.

Ce type de vulnérabilité exploite la manière dont différentes technologies et frameworks de serveurs gèrent paramètres dupliqués dans la même requête HTTPSi l'application n'est pas préparée à cela, un attaquant peut modifier la logique interne, contourner les validations, tromper les pare-feu d'applications Web (WAF) et même prendre le contrôle de fonctionnalités critiques telles que l'authentification ou la gestion des autorisations.

Concept de paramètres HTTP et de priorité

Sur pratiquement tous les sites web modernes, les utilisateurs envoient des données via Paramètres HTTP dans l'URL ou dans le corps de la requêteCes paramètres permettent au navigateur de transmettre des informations à l'application : recherches, données de formulaires, choix de sondages, commentaires, identifiants de connexion, etc.

Dans une requête GET classique, ces données transitent par le chaîne de requête (tout ce qui suit le signe ? dans l'URL)Les paires clé/valeur sont séparées par le symbole esperluette (&). Dans une requête POST, elles peuvent figurer dans le corps de la requête, mais la logique applicative côté serveur les traite généralement de manière très similaire : clés avec une ou plusieurs valeurs associées.

De nombreux langages de programmation et frameworks offrent des méthodes pour obtenir les deux. une valeur unique d'un paramètre comme la liste complète des valeurs si ce paramètre apparaît à plusieurs reprises. C'est courant, par exemple, avec cases à cocher permettant la sélection multiple, où le même nom de paramètre apparaît plusieurs fois.

Le problème survient lorsque le développeur suppose que Il n'y aura qu'une seule valeur par paramètre. et utilise des fonctions qui renvoient une seule valeur, alors que le navigateur (ou l'attaquant) envoie plusieurs valeurs portant le même nom. C'est là qu'un concept clé entre en jeu : priorité des valeurs.

Selon le langage, le framework et le serveur web, plusieurs occurrences du même paramètre peuvent entraîner différents comportements : que le première valeur reçuequ'il prend le dernière valeur ou qui est généré une combinaison de tous (par exemple, concaténés avec des virgules)Il n'existe pas de norme unique, chaque pile technologique peut donc se comporter différemment, ce qui ouvre la porte à des situations très dangereuses.

Le fait qu'une fonction ne renvoie qu'une seule valeur ne constitue pas une vulnérabilité en soi, mais cela l'est lorsqu'il y a Des paramètres dupliqués et le développeur n'en a pas connaissance. Selon le fonctionnement de cette priorité, l'application peut obtenir une valeur inattendue. C'est précisément ce comportement anormal que les techniques exploitent. Pollution des paramètres HTTP.

Qu'est-ce que la pollution des paramètres HTTP (HPP) ?

La pollution des paramètres HTTP est une technique qui consiste à injecter des paramètres supplémentaires ou des délimiteurs de chaîne de requête (encodé) au sein d'autres paramètres existants. Lorsque ce paramètre injecté est décodé et réutilisé pour générer une nouvelle URL ou pour construire une autre requête, l'application Il finit par intégrer des paramètres supplémentaires que le développeur n'avait pas prévus..

En d'autres termes, HPP exploite la manière dont l'application Il reconstruit les URL, traite les formulaires et gère les paramètres répétés.Si les données d'entrée ne sont pas correctement validées, un attaquant peut forcer l'application à interpréter des valeurs autres que celles attendues ou à inclure des paramètres supplémentaires dans les liens, les formulaires et les redirections.

Les techniques HPP ont été présentées publiquement par Stefano Di Paola et Luca Carettoni lors de la conférence OWASP AppSec 2009. Depuis lors, elles ont été documentées. de nombreux scénarios d'attaqueMais même aujourd'hui, elles ne bénéficient pas de la même visibilité que d'autres vulnérabilités mieux connues, et ne sont pas non plus entièrement couvertes par tous les outils automatisés.

L'impact d'une attaque par pollution des paramètres HTTP dépend en grande partie de logique particulière de l'applicationdu framework et du serveur web. Dans certains cas, les conséquences sont mineures (erreurs d'affichage, problèmes d'impression d'étiquettes, etc.), mais dans d'autres, cela peut signifier contournement de l'authentification, modification des autorisations ou manipulation des opérations critiques.

Pour que la vulnérabilité HPP soit réellement exploitable, le mécanisme de lecture des paramètres du serveur ou du framework doit être renvoie une valeur différente de celle attendue lorsqu'elle rencontre des paramètres dupliqués. À partir de là, l'attaquant peut manipuler cette priorité pour orienter le flux d'exécution de l'application à son avantage.

Comment les serveurs gèrent les paramètres dupliqués

L'élément technique clé qui rend possible le traitement des hautes pressions (HPP) réside dans le comportement inégal des différents fluides. Serveurs web et langages backend Lors du traitement de paramètres répétés, les méthodes varient d'un individu à l'autre, et c'est précisément cette diversité qui permet aux attaquants de trouver des vulnérabilités.

Dans certains environnements, si nous envoyons une URL du type variable1=val1&variable1=val2Le serveur ne conservera que les première valeur (val1). Dans d'autres cas, il faudra le dernière valeur reçue (val2). Et dans certains cas, comme c'est le cas avec certaines configurations de IIS, les deux valeurs sont concaténer en interne dans une liste, par exemple séparés par des virgules, que l'application devra ensuite interpréter.

Un exemple souvent cité est celui-ci : Apache Par défaut, il conserve généralement la première valeur d'un paramètre et ignore les suivantes, tandis que d'autres technologies génèrent une valeur unique. Liste CSV (Valeurs séparées par des virgules) avec toutes les valeurs de ce paramètre pollué. Si l'application backend n'est adaptée qu'à un seul de ces cas, des scénarios incontrôlés peuvent entraîner des effets inattendus.

Cette gestion des paramètres dupliqués affecte non seulement la logique visible pour l'utilisateur, mais aussi contrôles de sécurité internes, validateurs d'entrée, routines d'authentification et d'autorisationLe même paramètre peut être vérifié à un point de l'application avec une valeur, puis utilisé à un autre point avec une valeur différente, le tout au sein de la même requête.

De plus, les HPP peuvent être utilisées pour tirer parti de transformations internes du caractère ce que fait le serveur lui-même. Il a été documenté, par exemple, comment certains serveurs modifient certains caractères spécifiques (comme le caractère « ] » remplacé par « _ ») lors du traitement, ce qui peut être utilisé pour contourner les règles de filtrage ou les firmwares WAF basés sur des expressions régulières.

Conséquences et scénarios d'exploitation des centrales hydroélectriques

Les techniques de pollution des paramètres HTTP permettent de générer un large éventail de situations à risque, tant côté serveur que côté client. Leur gravité dépend de la fonction du paramètre affecté et point dans le flux d'application dans lequel il est modifié.

Parmi les conséquences les plus notables observées dans les applications vulnérables, on peut citer : écrasement des paramètres protégésUn attaquant peut ajouter plusieurs valeurs pour un paramètre critique et forcer l'application à utiliser précisément la valeur malveillante grâce au fonctionnement de la priorité des valeurs dans cet environnement spécifique.

Il est également courant que le traitement HPP permette modification du comportement attendu de l'applicationPar exemple, en modifiant les filtres des moteurs de recherche internes, en altérant les identifiants de ressources, en manipulant les opérations de vote ou en faisant varier les paramètres qui contrôlent la logique métier (tels que les indicateurs d'administration, les modes de débogage ou les états de transaction).

Une autre conséquence importante est la contournement des validations d'entréeSi le code de validation de sécurité examine la première occurrence d'un paramètre, mais que l'opération est effectuée avec une occurrence ultérieure, un attaquant peut contourner des contrôles de sécurité apparemment bien implémentés. Cela a été observé dans les cas suivants : contournement de l'authentification et du contrôle d'accès.

Dans des contextes plus complexes, HPP peut déclencher erreurs internes de l'application, divulgation d'informations sensibles, accès à des variables en dehors du périmètre prévu et même l'utilisation de paramètres concaténés qui, une fois réassemblés, forment des charges utiles qu'un WAF n'a pas détectées lors de l'analyse de chaque paramètre séparément.

En termes d'impact, des attaques ont été observées des deux côtés. du côté serveur (en contournant le WAF, en modifiant la réécriture d'URL et en forçant des routes internes différentes) à partir du côté client (injection de paramètres dans les liens et les formulaires pour tromper les victimes grâce à des URL spécialement manipulées).

Exemple classique de HPP dans une application de vote

Pour mieux comprendre le fonctionnement d'une attaque par pollution des paramètres HTTP, prenons l'exemple d'une Application web de vote écrite en JSPoù les utilisateurs sont autorisés à voter pour leur candidat préféré lors de différentes élections.

L'application reçoit via un paramètre appelé id_élection L'identifiant de l'élection en cours. Grâce à cette valeur, le serveur génère une page listant les candidats disponibles, chacun accompagné d'un lien permettant de voter. La méthode Request.getParameter("pair") En JSP, lorsqu'il existe plusieurs valeurs pour un même paramètre, la fonction renvoie toujours la valeur par défaut. première valeur.

Imaginons une URL comme celle-ci : http://servidor/eleccion.jsp?eleccion_id=4568La page qui s'affiche contient un lien permettant de voter pour chaque candidat, par exemple :

Lien 1Je vote pour M. White
Lien 2Je vote pour Mme Green

Supposons qu'un utilisateur malveillant, soutenant un candidat en particulier, se rende compte que l'application ne le fait pas valide avec succès le paramètre choice_idTirant parti d'une vulnérabilité HPP, il décide d'injecter le paramètre candidat dans cet identifiant de choix, encodant les délimiteurs de la chaîne de requête.

L'URL qu'il génère pourrait ressembler à ceci : http://servidor/eleccion.jsp?eleccion_id=4568%26candidato%3DgreenNotez que l'attaquant a encodé le symbole & comme %26 et le signe = comme %3D, de sorte qu'après décodage, ils deviennent un nouveau paramètre candidat intégré dans la valeur election_id.

Lorsque la victime clique sur cette URL manipulée, elle accède apparemment à l'élection correcte. Cependant, comme l'application utilise la valeur election_id pour construire les liens de vote, le décodage de la valeur injectée… Au final, un candidat supplémentaire est inclus dans la chaîne de requête résultante..

Le résultat est que les liens générés en interne ressemblent à ceci :

Lien 1Je vote pour M. White
Lien 2Je vote pour Mme Green

Peu importe sur lequel des deux liens la victime clique : le script voting.jsp reçoit toujours deux instances du paramètre candidatoù la première valeur est verte. Le développeur utilisant une fonctionnalité Java standard pour obtenir une seule valeur, il ne récupère que la première valeur du paramètre candidat et ignore la seconde, qui refléterait le vote réel de l'utilisateur.

Grâce à ce comportement, la vulnérabilité HPP permet à l'attaquant forcer tous les votes exprimés sur cette page à aller à leur candidatindépendamment des choix de la victime dans l'interface. Il s'agit d'un exemple très clair de la façon dont une gestion de paramètres supposément « simple » peut avoir un impact direct sur… intégrité des données et logique métier.

Contournement de l'authentification : le cas Blogger

L'un des exemples les plus notoires d'exploitation de la pollution des paramètres HTTP s'est produit dans le système de blogs de BloggerUne vulnérabilité dans la gestion des paramètres a permis aux attaquants d'accéder à devenir administrateurs des blogs d'autres personnessimplement en manipulant les paramètres d'une requête POST.

La requête problématique ressemblait à ceci (syntaxe simplifiée) :

POST /add-authors.do HTTP/1.1
security_token=attackertoken&blogID=attackerblogidvalue&blogID=victimblogidvalue&authorsList=attackermail%40gmail.com&ok=Inviter

Le problème résidait dans le fait que le mécanisme d'authentification et de vérification de sécurité Je regardais juste le premier paramètre blogID qui est arrivée dans la requête, vérifiant que l'utilisateur disposait des autorisations nécessaires sur ce blog. Cependant, l'opération réelle ajoutée par l'auteur invité a été effectuée à l'aide de deuxième occurrence de blogID, qui correspondait au blog de la victime.

Grâce à cette contradiction interne, la façon dont le serveur a géré le paramètres dupliquésL'attaquant a réussi à passer les contrôles de sécurité de son propre blog, mais a exécuté l'action sur l'autre blog. Le résultat a été un contournement complet de l'authentification avec une seule requête bien formulée.

Ce cas illustre parfaitement que le traitement HPP n'est pas une simple « curiosité technique », mais une technique à part entière. impacts réels sur les systèmes des grands fournisseursEn outre, cela souligne l'importance des contrôles de sécurité et de l'exécution des opérations en utilisant exactement les mêmes valeurs de paramètres, sans dépendre d'une priorité non contrôlée.

HPP et pare-feu d'applications Web (WAF)

De nombreuses organisations utilisent un WAF comme couche de protection supplémentaire pour leurs applications web contre les attaques connues. Ces pare-feu sont généralement basés sur… règles et signatures (expressions régulières) qui s'appliquent aux paramètres, aux en-têtes et même au corps des requêtes HTTP.

Le problème est que, en présence de paramètres dupliqués, un attaquant peut fragmenter une charge utile malveillante en plusieurs valeurs du même paramètreBien que le WAF analyse chaque paramètre séparément, il est possible qu'aucune des valeurs isolées ne corresponde aux signatures d'attaque, de sorte que la requête passe les filtres sans être bloquée.

Une fois que cette requête atteint le serveur web, le moteur d'application ou le serveur lui-même réassemble les valeurs selon sa logique interne (par exemple, en les concaténant avec des virgules ou en ne conservant que le dernier), ce qui donne une chaîne qui, dans son ensemble, constitue bien l'attaque. De cette manière, la même technique de pollution des paramètres permet contourner les WAF qui ne sont pas équipés pour analyser l'ensemble de valeurs concaténées.

De plus, certains WAF qui ne fonctionnent pas comme proxy inverse Et ceux qui n'ont pas une vue complète du flux entre le client et le serveur, mais qui agissent plutôt comme des filtres ponctuels, peuvent être particulièrement vulnérables à ces contournements HPP. Ceux basés sur des technologies telles que Apache avec un moteur de notation des paramètres et d'analyse statistique Ils ont tendance à mieux se comporter face à ce type de techniques.

En bref, HPP démontre que même avec un WAF correctement configuré, La sécurité n'est pas garantie Si la logique de l'application et du serveur gère mal les paramètres dupliqués, la protection doit être globale et prendre en compte la manière dont les requêtes sont traitées à tous les niveaux.

Cas réels, outils et prévalence de l'HPP

Les recherches universitaires et les travaux des experts en sécurité ont démontré que la pollution des paramètres HTTP est loin d'être rare. Des projets tels que PAPAS (Système d'analyse de la pollution par paramètres), sous l'impulsion de chercheurs comme Carmen Torrano, ont été conçus précisément pour Détection automatique des vulnérabilités HPP dans les applications web à grande échelle.

Dans des expériences menées sur plus de 5000 sites web très populaires (d'après les classements comme Alexa), on a observé que presque 30 % des sites analysés Elles contenaient au moins une page vulnérable à HPP. Autrement dit, il était possible d'injecter un paramètre encodé dans une autre page existante et de vérifier qu'il apparaissait décodé dans une URL ou un formulaire résultant.

Plus frappant encore, près de 47 % des vulnérabilités ont été découvertes (ce qui équivaut à environ 14 % du total des sites) étaient en réalité exploitablepermettant des attaques qui allaient au-delà de simples défauts de présentation. Parmi les sites touchés figuraient De grands noms comme Microsoft ou GoogleCela montre clairement que même les géants de la technologie ne sont pas exemptés de ces problèmes.

Des outils comme PAPAS Elles ont permis d'analyser et de quantifier le problème, mais elles ont également mis en évidence la difficulté de détection automatique HPPDe nombreux scanners de vulnérabilités Web traditionnels ne prennent pas suffisamment en compte les scénarios de paramètres dupliqués, ou génèrent un très grand nombre de faux positifs.

Outre des solutions spécifiques comme POTATOES, il existe des extensions comme HPP Finder pour Google ChromeCes outils sont conçus pour détecter les vecteurs d'attaque HPP potentiels dans les URL et les formulaires HTML. Bien qu'ils puissent aider à identifier les points suspects (par exemple, les formulaires qui réutilisent des paramètres sans validation adéquate), ils ne constituent pas une solution de repli. Il ne s'agit pas d'une solution complète ni d'un substitut à un audit de sécurité approfondi..

Un autre outil largement utilisé dans l'écosystème des tests de sécurité est OWASP ZAPqui comprend des extensions et des scripts pour tester différents vecteurs, notamment ceux liés aux paramètres de la chaîne de requête. Cependant, dans le cas spécifique de HPP, il reste nécessaire de combiner des outils automatisés avec analyse manuelle et compréhension du flux de l'application.

HPP dans les moteurs de recherche internes et des exemples comme Apple.com

Les HPP n'ont pas seulement été observés dans les systèmes de gestion de blogs ou les panneaux d'administration, ils apparaissent également dans des fonctions apparemment anodines telles que les moteurs de recherche par étiquette sur les forums et communautés en ligne. Un exemple frappant a été trouvé dans le Forums Apple, où la gestion des étiquettes et des paramètres pollués a révélé des comportements curieux.

Dans ces forums, la sélection d'une étiquette dans l'interface ajoutait un paramètre étiquettes La valeur de l'étiquette choisie a été transmise à la chaîne de requête de l'URL. L'application backend a récupéré cette valeur, recherché les sujets associés à cette étiquette et affiché les résultats à l'utilisateur. Si plusieurs étiquettes étaient sélectionnées, elles étaient toutes ajoutées. dans le même paramètre de balises, séparés par l'opérateur d'addition (+)Le système était donc prêt à traiter cette liste.

Lorsque le paramètre tags a été pollué par plusieurs valeurs dupliquées, on a observé que la technologie backend générait un liste séparée par des virgules (CSV) contenant toutes les valeurs de paramètres polluées. L'application a pu traiter partiellement cette liste (détecter les différentes étiquettes), mais L'impression des étiquettes n'était pas correcte. dans le champ de texte du moteur de recherche.

Dans ce contexte précis, il ne semblait pas y avoir de faille de sécurité exploitable, mais il était clair que Il existait des scénarios que les développeurs n'avaient pas envisagés.Dans d'autres applications, moins innocentes, un comportement similaire pourrait conduire à des divergences entre ce qui est validé, ce qui est utilisé et ce qui est affiché à l'utilisateur, avec des conséquences plus graves.

L'analyse des technologies sous-jacentes dans des forums tels que celui d'Apple (par exemple, Apache avec J2EE en backend) montre que de nombreuses piles modernes se comportent de manière similaire à des serveurs comme IIS ou à des combinaisons comme Apache avec Python lorsqu'il s'agit de gérer des paramètres pollués, en générant des listes séparées par des virgules et en déléguant le traitement final de ces valeurs à la logique de l'application.

Ce type d'exemples sert à nous rappeler que Il ne suffit pas que cela « semble fonctionner » dans les cas normaux.Il faut tester systématiquement comment l'application réagit lorsqu'elle reçoit des paramètres dupliqués, des valeurs étrangement codées, des combinaisons inhabituelles, etc., car c'est là que HPP trouve sa niche.

Détection et atténuation de la pollution des paramètres HTTP

La détection et l'atténuation des HPP nécessitent une approche hybride qui combine de bonnes pratiques de développement sécurisé, une configuration serveur appropriée et l'utilisation d'outils spécifiquesIl ne suffit pas de compter sur le WAF pour tout corriger, car comme nous l'avons vu, c'est bien souvent cette couche qui peut être trompée.

Du point de vue du développement, il est essentiel que les programmeurs Sachez qu'un paramètre peut avoir plusieurs valeurs. Ils doivent donc décider explicitement de la marche à suivre. Ils ne doivent pas se fier aux comportements par défaut du langage ou du framework sans une compréhension approfondie du fonctionnement de la priorité des valeurs.

Il est également recommandé que, aux points critiques tels que authentification, autorisation, opérations sensibles ou changements d'état importantsIl est strictement vérifié que les paramètres n'apparaissent qu'une seule fois, les requêtes comportant des paramètres dupliqués étant rejetées ou, à tout le moins, consignées pour analyse.

En ce qui concerne l'infrastructure, il est conseillé de revoir Configurations du serveur web et du framework Pour comprendre précisément ce qui se passe lorsqu'un paramètre répété est reçu : est-ce que le premier, le dernier ou leur concaténation sont conservés ? En fonction de ces informations, la logique de l'application peut être ajustée afin d'éviter les incohérences entre la validation et l'utilisation réelle de la valeur.

En matière d'outils, outre les scanners de vulnérabilités habituels, il est utile d'intégrer des solutions ciblées telles que PAPAS ou types d'extensions HPP Finder dans le flux de test. Si OWASP ZAP ou d'autres outils de test d'intrusion sont utilisés, il est judicieux de concevoir des scripts spécifiques qui génèrent requêtes avec des paramètres et des valeurs dupliqués codés de différentes manières observer la réaction de l'application.

Enfin, il est important de reconnaître que le traitement HPP est un problème beaucoup plus répandu qu'on ne le pense généralementCela est particulièrement vrai pour les applications de grande envergure ayant évolué au fil des années. La combinaison de la formation, de la revue de code, des tests automatisés et des tests manuels bien conçus constitue la meilleure façon de maîtriser ces erreurs.

La contamination des paramètres HTTP a amplement mérité sa place parmi les techniques d'attaque web que toute équipe de développement et de sécurité devrait surveiller : Elle est discrète, difficile à déceler d'un simple coup d'œil aux bûches, et peut avoir des conséquences très graves. Si cela affecte des paramètres clés de la logique métier ou des contrôles de sécurité, il est crucial de comprendre comment les paramètres dupliqués sont gérés dans votre architecture et de tester activement ces scénarios. Bien que cela puisse paraître fastidieux au premier abord, c'est ce qui fait toute la différence entre une application simplement fonctionnelle et une application véritablement robuste face aux attaques sophistiquées.