Les injections représentent la vulnérabilité la plus utilisée et la plus répandue pour accéder à des zones mémoires illégales par débordement de tampon (over ow) ou bien pour modifier le flot de contrôle par interprétation d’instructions indésirables (overrun). Ces attaques per- mettent la lecture de données confidentielles, voire l’exécution de commandes et de fichiers malveillants. L’OWASP1établit périodiquement la liste des dix plus grandes vulnérabilités des applications Web. Parmi les deux dernières éditions de 2007 et 2010 (tableau récapitulatif joint en annexe), plus des deux tiers des vulnérabilités concernent ou peuvent être menées par des injections.
La tendance du volume d’attaques menées vers des serveurs est en constante évolution mois après mois. En figure 5.1, une étude chiffre les attaques constatées en début 2010.
Dans ce chapitre, une explication sur le fonctionnement et le potentiel des injections est faite dans une première section. La deuxième section présente un état de l’art des techniques d’analyses. Enfin, une synthèse est proposée en présentant les bonnes pratiques à adopter pour détecter et supprimer les points d’injection d’un système en agissant uniquement sur le code source de l’application. Une brève description de l’ensemble des vulnérabilités liées à des injections malicieuses identifiées par l’OWASP est présentée en annexe figure E.1, page 143.
FIGURE 5.1 – Volume d’attaques constatées par mois. (crédits HP TippingPoint DVLabs et Qualys)
5.2.1 Une injection, qu’est-ce que c’est ?
Le but d’une attaque par injection est de modifier le flot d’exécution d’une application par insertion d’instructions dans des points d’entrée censés recevoir uniquement des données. De cette façon, le comportement de l’application peut devenir maîtrisable par l’attaquant si ses entrées ne sont pas filtrées.
En Java, les allocations de mémoire étant entièrement gérées par la machine virtuelle, les attaques par débordement de tampons sont impossibles. Cependant, lorsqu’une méthode in- voque un service tiers qui n’est plus dans un contexte java, des limites de taille de données doivent être respectées pour garantir un bon fonctionnement. C’est dans ce cadre qu’un élé- ment peut être étiqueté comme attaquable par débordement de tampon à partir d’un contexte Java.
Les injections se déclinent sous diverses formes sur une grande variété de systèmes d’infor- mation et de technologies. Le tableau 5.1 les décrit brièvement. Elles sont détaillées en annexe E.
FIGURE5.2 – Schéma de fonctionnement d’une application Web
FIGURE5.3 – Exemple de faille d’injection dans une jsp.
5.2.2 Cibles d’injections
Les points d’injection d’une application sont principalement les champs des formulaires Web, les adresses URL lorsque des paramètres sont ajoutés dynamiquement, les cookies et aussi les champs cachés des formulaires. Il est possible aussi de manipuler directement les trames http en les interceptant pendant leur transit sur le réseau, ou bien en les forgeant intégra- lement. Lorsque la requête contenant l’injection parvient à l’application Web, si celle-ci n’est pas sécurisée, elle va exécuter la commande normalement prévue ainsi que celles qui ont été injectées. L’exécution des commandes injectées peut intervenir directement lors de l’attaque, ou bien ultérieurement et de manière répétée pour les injections persistantes. Des exemples d’injections persistantes sont celles qui défigurent les pages html (defacement) par corruption de cache proxy.
Type d’attaque2 Attaque dirigée v ers Corruption de paramètres ’cachés’ Manipulation de trames http/d’en-tête Insertion d’instructions dans des champs publics But de l’attaque
Argument Injection or Modification serveur X 33 X Construire des requêtes illégales
Code / Command Injection serveur 3 X Exécution de commandes Direct Static Code Injection (SSI par ex.) serveur 3 3 sur le serveur
Cross-site-scripting (XSS) client 3 3 3 Corruption d’un site, redirection des usagers Cross Frame Scripting (XFS) client 3 3 3 vol d’informations personnelles, usurpation d’identité Cross-site-Request forgery (XSRF-CSRF) client X 3 3 usurpation d’identité
Format string attack serveur 3 3 Accès zone mémoire pour modifier le fonctionnement de l’application
SQL Injection serveur 3 X Exécution de commandes SQL,
XPATH Injection serveur 3 X XPATH et
LDAP injection serveur 3 X LDAP illégales
Log injection serveur 3 X Corruption du fichier de log sur serveur Response Splitting / Smuggling attack serveur X X Defacement -> possibilité de XSS et XFS. Special Element Injection serveur X 3 X Fonctionnement errroné du système Path traversal, Path manipulation, forceful browsing serveur X Accès ressources interdites sur le serveur Web Parameter Tampering serveur X Création de requêtes illégales
TABLE5.1 – Tableau récapitulatif des types d’injections connues à ce jour concernant les ap- plications Web.
5.2.3 Potentiel d’une attaque
Une injection peut permettre de :
– Accéder à des ressources confidentielles, – Corrompre des données,
– Lancer des commandes sur le serveur,
– Envoyer des données, du code sur le serveur (afin de faire héberger du contenu illégal par exemple, ou pour installer unrootkit),
– Usurper une identité,
– Modifier le comportement et/ou le visuel d’un site, rediriger les clients ultérieurs du site, leur subtiliser des données privées. . .
Le tableau 5.1 donne un aperçu des différentes formes d’injections connues actuellement. Il précise pour chaque méthode vers qui l’attaque est dirigée, son but et les techniques les plus couramment employées pour y parvenir.
2. Une description avec exemple est fournie en annexe 3. 3 = "possible"
5.2.4 Technique de défense
L’utilisation d’Intrusion Detection Systems (IDS4) et d’Intrusion Prevention Systems (IPS5) peut s’avérer inefficace pour parer à ce type d’attaques. Effectivement leur détection de motifs de code dans le trafic n’est pas assez fine pour couvrir le polymorphisme des méthodes ac- tuelles. Ils restent cependant efficaces pour bloquer le trafic généré par les virus tels que Code Red ou Nimda. De plus, leur système d’analyse statistique d’anomalie retourne une quantité de faux positifs dans lesquels une attaque peut rester assez discrète. . .
La solution pour s’assurer de l’élimination des failles de sécurité permettant des injections est de procéder à une validation des données entrantes dans le code de l’application Web qui va fil- trer les contenus indésirables. Dans certains cas, ce filtrage doit pouvoir se moduler en fonction de variables donnant des informations dynamiques sur le contexte6.