Jcpraud at 17:50, 5 January 2015

2015-01-05T17:50:06Z

Jcpraud: Created page with "{{Template:OWASP Testing Guide v4}} == Sommaire ==
Fournir plusieurs paramètres HTTP de même nom peut induire l'application à en interprêter les valeurs de manière..."

2015-01-05T17:47:48Z

Created page with "{{Template:OWASP Testing Guide v4}} == Sommaire == Fournir plusieurs paramètres HTTP de même nom peut induire l'application à en interprêter les valeurs de manière..."

New page

{{Template:OWASP Testing Guide v4}}

== 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 [http://www.ietf.org/rfc/rfc3986.txt RFC 3986] définit seulement le terme ''Query String'' comme une série de paires champs-valeur et la [http://www.ietf.org/rfc/rfc2396.txt 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 : <code>select 1,2,3 from table</code>, empêchant ainsi cette URL d'être traîtée par le serveur web : <code>/index.aspx?page=select 1,2,3 from table</code>. 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 <code>/index.aspx?page=select 1&page=2,3</code> 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 : <code>http://127.0.0.1:631/admin/?kerberos=onmouseover=alert(1)&kerberos</code>. Le mécanisme de vérification de l'application pouvait être contourné en ajoutant un argument <code>kerberos</code> 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 <code>kerberos</code> 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 :

<code>
POST /add-authors.do HTTP/1.1

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

La faille se trouvait dans le mécanisme d'authentification utilisé par l'application web, puisque la vérification se faisait sur le premier <code>blogID</code>, 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 : <code>http://example.com/?couleur=rouge&couleur=bleu</code>
{|
|-
! Serveur d'application web !! Résultat d'analyse !! Exemple
|-
| ASP.NET / IIS || Toutes les occurences sont concaténées avec des virgules || couleurr=rouge,bleu
|-
| ASP / IIS || Toutes les occurences sont concaténées avec des virgules|| color=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 || color=['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 <code>search_string</code>, l'URL de la requête contiendra ce paramètre et cette valeur.
 <code>http://example.com/?search_string=chatons</code>
 

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.
 
<code>http://example.com/?mode=guest&search_string=chatons&num_results=100</code>
 
Ajouter le même paramètre avec une valeur différente
 
<code>http://example.com/?mode=guest&search_string=chatons&num_results=100&search_string=chiots</code>
 
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 <code>kittens</code>, <code>puppies</code>, une combinaison des deux (<code>kittens,puppies</code> or <code>kittens~puppies</code> ou <code>['kittens','puppies']</code>), 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 :
# Envoyer une requête HTTP contenant les paramètres et valeurs normaux, et enregistrer la réponse HTTP. Par exemple <code>page?par1=val1</code>
# Remplacer la valeur du paramètre par une valeur modifiée, envoyer la requête et enregistrer la réponse. Par exemple <code>page?par1=HPP_TEST1</code>
# Envoyer une requête combinant les étapes (1) et (2). Enregistrer aussi la réponse HTTP. Par exemple <code>page?par1=val1&par1=HPP_TEST1</code>
# 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 <code>%26HPP_TEST</code> et chercher les occurences ''url-decoded'' dans les données fournies par l'utilisateur :
* <code>&HPP_TEST</code>
* <code><tt>&amp;HPP_TEST</tt></code>
* … and others

En particulier, il faut examiner les réponses contenant des vecteurs HPP dans les attributs ou actions de formulaires <code>data</code>, <code>src</code>, <code>href</code>. 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 [https://code.google.com/p/zap-extensions/wiki/V1Extensions]

HPP Finder (Chrome Plugin) [https://chrome.google.com/webstore/detail/hpp-finder]

== Références ==
'''Whitepapers''' 
HTTP Parameter Pollution - Luca Carettoni, Stefano di Paola [https://www.owasp.org/images/b/ba/AppsecEU09_CarettoniDiPaola_v0.8.pdf]

Split and Join (Bypassing Web Application Firewalls with HTTP Parameter Pollution) - Lavakumar Kuppan [http://www.andlabs.org/whitepapers/Split_and_Join.pdf]

Client-side Http Parameter Pollution Example (Yahoo! Classic Mail flaw) - Stefano di Paola [http://blog.mindedsecurity.com/2009/05/client-side-http-parameter-pollution.html]

How to Detect HTTP Parameter Pollution Attacks - Chrysostomos Daniel [http://www.acunetix.com/blog/whitepaper-http-parameter-pollution/]

CAPEC-460: HTTP Parameter Pollution (HPP) - Evgeny Lebanidze [http://capec.mitre.org/data/definitions/460.html]

Automated Discovery of Parameter Pollution Vulnerabilities in Web Applications - Marco Balduzzi, Carmen Torrano Gimenez, Davide Balzarotti, Engin Kirda [http://www.iseclab.org/people/embyte/papers/hpp.pdf]

@@ Line 47: / Line 47: @@
 ! Serveur d'application web !! Résultat d'analyse !! Exemple
 |-
-| ASP.NET / IIS || Toutes les occurences sont concaténées avec des virgules || couleurr=rouge,bleu
+| 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|| color=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
@@ Line 71: / Line 71: @@
 | mod_wsgi (Python) / Apache || La première occurence est conservée || couleur=rouge
 |-
-| Python / Zope || Toutes les occurences sont dans une liste || color=['rouge','bleu']
+| Python / Zope || Toutes les occurences sont dans une liste || couleur=['rouge','bleu']
 |}
 (source: [[Media:AppsecEU09_CarettoniDiPaola_v0.8.pdf]] )

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

Jcpraud at 17:50, 5 January 2015

Jcpraud: Created page with "{{Template:OWASP Testing Guide v4}} == Sommaire == Fournir plusieurs paramètres HTTP de même nom peut induire l'application à en interprêter les valeurs de manière..."

Jcpraud: Created page with "{{Template:OWASP Testing Guide v4}} == Sommaire ==
Fournir plusieurs paramètres HTTP de même nom peut induire l'application à en interprêter les valeurs de manière..."