La technique de pollution de paramètres et cookies permet d’exploiter des vulnérabilités au sein d’une application Web. Cette nouvelle forme d’attaque a été présentée pour la première fois à la conférence OWASP Europe 2009 par Stéphano di Paola et Luca Carettoni.
Deux exemples de pollution de paramètres :
http://www.hostname.com/index.asp?var1=val1&var2=val2&var1=val3
Dans ce premier exemple, on peut trouver la variable var1 deux fois, ce qui dans certains Frameworks va déclencher différents comportements, comme par exemple, concaténer les deux valeurs pour la variable.
http://www.hostname.com/index.asp?var1=val1+val3
Il est aussi possible de faire une attaque par brute force sur le nom des variables pour déclencher certains comportements anormaux. Selon le Framework et le langage utilisé, il devient possible d’accéder et d’écraser certaines variables dans le code en les passant directement en paramètres.
http://www.hostname.com/index.php?db_login=test&db_password
Cette attaque tentera d’écraser les variables de crédentiels pour se connecter à la base de données. Si l’attaque réussit, plusieurs messages d’erreurs apparaitrons à l’écran et il sera possible par exemple de faire de l’élévation de privilège et d’accéder à plus de données.
Le firewall applicatif :
Un firewall applicatif permet de filtrer chaque partie d’une requête HTTP. Il peut fonctionner sur un modèle de détection négatif (blacklist) qui bloquera certaines chaines de caractères ou positif (whitelist) qui les autorisera. Le résultat de ces différents modèles de détection entraineront le blocage de la requête en cas d’attaque détectée.
Dans le cas présent, il existe deux techniques possibles pour bloquer la pollution de paramètres :
- Apprendre les différentes variables pouvant être appelées sur chaque ressource dynamique. Une fois l’apprentissage terminé, si un client essaye de passer un paramètre non connu, qui pourrait donc permettre un écrasement de valeur lors de l’exécution du script dynamique, la requête sera bloquée. Par exemple, un paramètre contenant le mot de passe pour accéder à la base de donnée ne passera jamais dans une requête et ne sera jamais appris sur du trafic sain. Il sera bloqué si quelqu’un tente de le passer dans une requête.
- Activer la sanitization des requêtes pour réagir à un cas de figure d’une variable en double avec deux valeurs différentes. Dans ce cas là, la normalisation de la requête devra transformer les deux variables en une seule, avec un seul contenu. Du coup, les mécanismes de blacklist et de whitelist pourront travailler sur une valeur globale et détecter toute tentative de splitting d’attaque en plusieurs valeurs. Par exemple :
http://www.hostname.com/index.php?login=test’OR@name=test@login=%201=1
La variable login sera contrôlée avec la valeur test’OR 1=1 ce qui sera bloqué pour SQL Injection.
La whitelist ou modèle de blocage positif d’un firewall applicatif permet de se prémunir contre la pollution de paramètre et l’écrasement de variables. Ses différentes fonctionnalités de normalisation et sanitization des requêtes doivent aussi être capables de présenter une requête propre aux différents moteurs de détections.
Le système d’apprentissage de la Sitemap d’i-Suite ainsi que les différentes routines de nettoyage des requêtes du moteur ICX permettent par exemple de protéger efficacement contre ces attaques.
Matthieu Estrade
Image : © Pixel
Si vous désirez rejoindre notre mailing list, veuillez entrer votre email ci-dessous. 
Loading ...
Suivez-nous…