4.8.4 Test d'HTTP Parameter pollution (OTG-INPVAL-004)

This article is part of the new OWASP Testing Guide v4.

Back to the OWASP Testing Guide v4 ToC:
   https://www.owasp.org/index.php/OWASP_Testing_Guide_v4_Table_of_Contents
Back to the OWASP Testing Guide Project:
   https://www.owasp.org/index.php/OWASP_Testing_Project

Sommaire

Fournir plusieurs paramètres HTTP de même nom peut induire l'application à en interprêter les valeurs de manière imprévue. En exploitant ces effets, un attaquant peut contourner la validation des entrées, déclencher des erreurs de l'application, ou modifier la valeur de variables. Comme l'HTTP Parameter Pollution (HPP) impacte une brique commune à toute les technologies web, des attaques côté serveur et client sont possibles.

Les standard HTTP actuels n'imposent pas de méthode pour l'interprêtation de paramètres multiples portant le même nom. Par exemple, la RFC 3986 définit seulement le terme Query String comme une série de paires champs-valeur et la RFC 2396 définit des classes de caractères réservés et non réservés. Sans standard en place, les composants d'application web traitent ce cas limite de façon variée (voir la table ci-dessous pour plus de détails).

En soit cela n'est pas un indicateur de vulnérabilité. Cependant, si le développeur n'est pas averti du problème, la présence de paramètres dupliqués peut entraîner une anomalie de comportement dans l'application, pouvant être exploitée par un attaquant. Comme souvent en sécurité, les comportements inattendus sont souvent une source de faiblesses qui peuvent causer des attaques par HTTP Parameter Pollution. Pour mieux présenter cette classe de vulnérabilités et leur effets, il est intéressant d'analyser quelques exemples réels.

Contournement de validation d'entrées et de filtres

En 2009, immédiatement après la publication du premier travai lde recherche sur l'HTTP Parameter Pollution, la technique a reçu l'attention de la communauté de la sécurité comme possible manière de contourner les pare-feux applicatifs web.

Une de ces failles, impactant ModSecurity SQL Injection Core Rules, représente un exemple parfait de décalage entre applications et filtres. Le filtre ModSecurity mettrait correctement sur liste noire la chaîne suivante : select 1,2,3 from table, empêchant ainsi cette URL d'être traîtée par le serveur web : /index.aspx?page=select 1,2,3 from table. Cepdendant, en exploitant la concaténation de multiples paramètres HTTP, un attaquant pourrait faire en sorte que le serveur d'application concatène la chaîne après que le filtre de ModSecurity ait accepté la requête. Par exemple, l'URL /index.aspx?page=select 1&page=2,3 from table ne déclencherait pas le filtre ModSecurity, pourtant la couche applicative concatènerait l'entrée en une chaîne malicieuse complète.

Il s'est avéré qu'une autre vulnérabilité HPP a impacté Apple Cups, le système d'impression bien connu utilisé par beaucoup de systèmes UNIX. En exploitant une HPP, un attaquant pouvait facilement déclencher une vulnérabilité Cross-Site Scripting en utilisant l'URL : http://127.0.0.1:631/admin/?kerberos=onmouseover=alert(1)&kerberos. Le mécanisme de vérification de l'application pouvait être contourné en ajoutant un argument kerberos ayant une chaîne valide (par exemple une chaîne vide). Comme le mécanisme de validation ne vérifiait que la seconde occurence, le premier kerberos n'était pas proprement nettoyé avant d'être utilisé pour générer du contenu HTML dynamique. Une exploitation réussie pouvait permettre l'exécution de code JavaScript dans le contexte du site web hébergeant l'application.

Contournement d'authentification

Une vulnérabilité HPP encore plus critique a été découverte sur la plateforme populaire de blog Blogger. Le bogue permettait à des utilisateurs malicieux de prendre le contrôle du blog d'une victime en utilisant la requête HTTP suivante :

POST /add-authors.do HTTP/1.1

security_token=attackertoken&blogID=attackerblogidvalue&blogID=victimblogidvalue&authorsList=goldshlager19test%40gmail.com(attacker email)&ok=Invite

La faille se trouvait dans le mécanisme d'authentification utilisé par l'application web, puisque la vérification se faisait sur le premier blogID, alors que l'opération utilisait la seconde occurence.

Comportement attendu par le serveur d'application

La table suivante illustre comment différentes technologies web se comportent en présence de multiples occurences du même paramètre HTTP.

Pour une URL et sa chaine de paramètres données : http://example.com/?couleur=rouge&couleur=bleu

Serveur d'application web	Résultat d'analyse	Exemple
ASP.NET / IIS	Toutes les occurences sont concaténées avec des virgules	couleur=rouge,bleu
ASP / IIS	Toutes les occurences sont concaténées avec des virgules	couleur=rouge,bleu
PHP / Apache	La dernière occurence est conservée	couleur=bleu
PHP / Zeus	La dernière occurence est conservée	couleur=bleu
JSP, Servlet / Apache Tomcat	La première occurence est conservée	couleur=rouge
JSP, Servlet / Oracle Application Server 10g	La première occurence est conservée	couleur=rouge
JSP, Servlet / Jetty	La première occurence est conservée	couleur=rouge
IBM Lotus Domino	La dernière occurence est conservée	couleur=bleu
IBM HTTP Server	La première occurence est conservée	couleur=rouge
mod_perl, libapreq2 / Apache	La première occurence est conservée	couleur=rouge
Perl CGI / Apache	La première occurence est conservée	couleur=rouge
mod_wsgi (Python) / Apache	La première occurence est conservée	couleur=rouge
Python / Zope	Toutes les occurences sont dans une liste	couleur=['rouge','bleu']

(source: Media:AppsecEU09_CarettoniDiPaola_v0.8.pdf )

Comment tester

Par chance, comme l'affectation des paramètres HTTP se fait typiquement dans le serveur d'application, et non dans le code applicatif lui-même, tester les réponses à la pollution de paramètres devrait se faire de manière uniforme sur toutes les pages et actions. Cependant, comme cela nécessite une connaissance approfondie de la logique applicative, tester les HPP requière des tests manuels. Les outils automatiques ne peuvent assister que partiellement les auditeurs, puisqu'ils tendent à générer trop de faux positifs. De plus, une HPP peut se manifester côté client comme côté serveur.

HPP côté serveur

Pour tester les vulnérabilités HPP, il faut identifier les formulaires ou actions qui acceptent des entrées utilisateur. Les chaînes de paramètres des requêtes HTTP GET sont faciles à modifier dans la barre de navigation du navigateur. Pour les actions de formulaires envoyées en POST, le testeur devra utiliser un proxy pour intercepter et modifier les données POST lorsqu'elles sont envoyées vers le serveur. Après avoir identifié un paramètre d'entrée particulier à tester, on peut éditer les données GET ou POST en interceptant la requête, ou changer la chaîne de paramètre après le chargement de la page de réponse. Pour tester les vulnérabilités HPP, ajouter simplement le même paramètre aux données GET ou POST mais avec une valeur différente.

Par exemple : si l'on test le paramètre search_string, l'URL de la requête contiendra ce paramètre et cette valeur.
http://example.com/?search_string=chatons

Le paramètre à tester peut être caché parmi les autres paramètres, mais l'approche est la même ; laisser les autres paramètres en place et ajouter le duplicat.
http://example.com/?mode=guest&search_string=chatons&num_results=100
Ajouter le même paramètre avec une valeur différente
http://example.com/?mode=guest&search_string=chatons&num_results=100&search_string=chiots
et envoyer la requête.

Analyser la page de réponse pour déterminer quelle(s) veleur(s) ont été prise(s) en compte. Dans l'exemple précédent, le résultat de la recherche peut afficher kittens, puppies, une combinaison des deux (kittens,puppies or kittens~puppies ou ['kittens','puppies']), peut donner un résultat vide, une page d'erreur.

Il est probable que ce comportement (première, dernière ou combinaison des paramètres de même nom) soit le même pour toute l'application. Qu'il indique ou non une vulnérabilité dépend des validations et filtrages spécifiques à l'application. En règle générale : si les validations d'entrée et les autres mécanismes de sécurité suffisent pour une valeur unique, et que le serveur affecte seulement le premièr ou le dernièr paramètre pollué, alors cela n'indique pas de vulnérabilité. Si les paramètres sont concaténés, si différents composants de l'application web utilisent différentes occurences, ou si les tests produisent des erreurs, il y a une probabilité plus grande de pouvoir utiliser la pollution de paramètres pour déclencher des vulnérabilités de sécurité.

Une analyse plus détaillée demanderait trois requêtes HTTP pour chaque paramètre :

1. Envoyer une requête HTTP contenant les paramètres et valeurs normaux, et enregistrer la réponse HTTP. Par exemple page?par1=val1
2. Remplacer la valeur du paramètre par une valeur modifiée, envoyer la requête et enregistrer la réponse. Par exemple page?par1=HPP_TEST1
3. Envoyer une requête combinant les étapes (1) et (2). Enregistrer aussi la réponse HTTP. Par exemple page?par1=val1&par1=HPP_TEST1
4. Comparer les réponses obtenues lors de toutes les étapes précédentes. Si la réponse (3) est différente de (1) et aussi de la réponse (2), il y a un décalage qui peut être utilisé pour déclencher des vulnérabilités HPP.

Construire une exploitation complète à partir d'une faiblesse de pollution de paramètres sort du cadre de ce texte. Voir les références des exemples et plus de détails.

HPP côté client

De manière similaire aux tests HPP côté serveur, les tests manuels sont la seule technique fiable pour auditer les applications web et détecter les vulnérabilités de pollution de paramètre impactant les composants côté client. Alors que dans la variante côté serveur l'attaquant utilise une application web vulnérable pour accéder à des données protégées ou effectuer des ations interdites, les attaques côté client visent à subvertir les composants et technologies côté client.

Pout tester les vulnérabilités HPP côté client, il faut identifier tout formulaire ou action acceptant des entrées utilisateur et affichant un résultat dépendant de ces entrées. Une page de recherche est idéale, mais une boite de connexion peut ne pas fonctionner (puisqu'elle n'affichera pas d'identifiant invalide en retour à l'utilisateur).

De la même manière que pour les HPP côté serveur, il faut polluer chaque paramètre HTTP avec %26HPP_TEST et chercher les occurences url-decoded dans les données fournies par l'utilisateur :

• &HPP_TEST
• &HPP_TEST
• … and others

En particulier, il faut examiner les réponses contenant des vecteurs HPP dans les attributs ou actions de formulaires data, src, href. Encore une fois, que ce comportement par défaut signale une vulnérabilité dépend des validations d'entrées et filtrages spécifiques, et de la logique applicative. De plus, il est important de noter que cette vulnérabilité peut aussi impacter les paramètres utilisés dans XMLHttpRequest (XHR, la création des attributs runtime et autres technologies de plugins (par exemple les variables flashvars d'Adobe Flash).

Tools

OWASP ZAP HPP Passive/Active Scanners [1]

HPP Finder (Chrome Plugin) [2]

Références

Whitepapers
HTTP Parameter Pollution - Luca Carettoni, Stefano di Paola [3]

Split and Join (Bypassing Web Application Firewalls with HTTP Parameter Pollution) - Lavakumar Kuppan [4]

Client-side Http Parameter Pollution Example (Yahoo! Classic Mail flaw) - Stefano di Paola [5]

How to Detect HTTP Parameter Pollution Attacks - Chrysostomos Daniel [6]

CAPEC-460: HTTP Parameter Pollution (HPP) - Evgeny Lebanidze [7]

Automated Discovery of Parameter Pollution Vulnerabilities in Web Applications - Marco Balduzzi, Carmen Torrano Gimenez, Davide Balzarotti, Engin Kirda [8]