Dans la cybersécurité, l’injection de code est comparable à un vaccin, sauf qu’elle est loin de garantir votre santé. Voyez-la plutôt comme une piqûre d’insectes dans vos applications web. À mesure que les services numériques et les applications web sont adoptés dans les entreprises, cela multiplie la surface d’attaque. Pourtant, une attaque par injection de code menace aussi bien les données utilisateurs que la réputation de l’entreprise.
Il faut considérer l’injection de code comme une faille de sécurité sérieuse. L’attaquant l’exploite en insérant du code malveillant dans une application, provoquant des actions non autorisées. Si l’injection SQL est le plus connu, d’autres types d’attaques sont aussi dévastateurs. Une meilleure compréhension de cette forme de cyberattaque vous permet de mieux sécuriser votre infrastructure. Voyons cela dans l’article.
Qu’est-ce que l’injection de code ?
L’injection de code est une pratique de hackers très ancienne qui remonte aux années 90 avec l’apparition du CGI (common gateway interface). Les hackers réalisent rapidement que les serveurs font confiance facilement aux données envoyées via les formulaires. Dès 1998, Jeff Forristal publie un article très documenté sur l’injection SQL dans Phrack. Cependant, celui-ci n’est pas pris au sérieux par les principaux acteurs du web de l’époque, dont Microsoft.
Pourtant, l’avènement d’internet dans les années 2000 et du web 2.0 marque un tournant avec l’explosion des attaques SQL et XSS. En 2018, un rapport de Imperva révélait qu’elle représentait 18% des attaques contre les applications web. Le but de cette technique d’attaque consiste à trouver des failles dans une application et d’y injecter du code. Résultat : du code non autorisé s’exécute sur le serveur.
Les attaquants exploitent la principale faille des applications : les entrées des utilisateurs, c’est-à-dire là où les données de l’utilisateur rencontrent le backend. Il peut s’agir des champs de saisie de formulaire, les points de terminaison API, les en-têtes http, les paramètres d’URL, voire les fichiers téléchargés. Les attaquants tirent également profit de la faiblesse de validation des entrées et des pratiques de codage non sécurisées. Prenons l’exemple d’un mauvais codage de la section des commentaires. On peut l’exploiter pour y insérer une requête malveillante.
Comment se déroule une attaque par injection de code ?
Une attaque par injection de code vise spécialement les applications d’entreprise. Pour cause, ces dernières traitent régulièrement des entrées d’utilisateurs. Pourtant, ces entrées peuvent être manipulées pour atteindre un but malveillant. Les attaquants procèdent en plusieurs étapes :
Repérage d’un point d’entrée
Le hacker repère et observe les champs de saisie et les canaux de communication entre l’application et l’utilisateur : paramètres de requête, champs de formulaire, champs de commentaire, etc. Pour cela, il utilise les mêmes outils de proxys d’interception que les pentesters comme Burpsuite et Owasp ZAP. Ce type d’outils permet d’identifier les requêtes derrière l’interface.
Injection du code malveillant
L’attaquant a déjà conçu son code malveillant (charge utile) et va l’injecter via le point d’entrée repéré. Ce code est similaire à une entrée valide mais il comprend des instructions exécutables. Sa syntaxe est irréprochable pour éviter tout plantage du serveur. Par exemple, au lieu de saisir un nom dans le champ dédié, il écrit « admin’– ».
Gestion incorrecte des entrées
L’application ne reconnaît pas ce code clandestin, le considérant comme légitime. Pourtant, elle ne le traite pas comme un texte, mais comme une instruction.
Exécution du code
C’est l’étape où le système de sécurité échoue à détecter une instruction malveillante et l’exécute. Dans le cas d’une attaque par injection XSS par exemple, dès qu’un visiteur atterrit sur une page web, son navigateur exécute également le code, entraînant ainsi un effet de contamination.
Exploitation
Nous voici à l’étape ultime de ce type d’attaque. La phase d’exploitation est marquée par les dégâts de l’injection. Dans le cas d’une injection SQL par exemple, l’attaquant siphonne toute la table des cartes bancaires vers son appareil. Cela peut aussi être une simple modification du code HTML du site pour afficher des publicités offensantes ou des images politiques qui compromettent la réputation de la marque.
Impacts d’une injection de code sur l’organisation
Une attaque par injection de code peut remplir des objectifs variés. Dans tous les cas, les impacts sur l’organisation sont dévastateurs :
Exfiltration de données
Il s’agit là de la principale motivation des attaquants. Si ces derniers y parviennent, c’est une hémorragie de données sensibles comme la propriété intellectuelle, les identifiants d’utilisateurs, les données financières. De plus, de simples scripts SQL permettent d’automatiser l’exfiltration de millions de lignes d’informations en quelques minutes.
L’agence de crédit Equifax en est l’exemple. En 2017, l’entreprise fait face à une attaque par injection de code qui entraîne l’exposition des données de 147 millions d’utilisateurs. Pour Equifax, cette attaque a coûté le milliard de dollars.
Compromission du système
Si le code injecté octroie un contrôle administratif ou élève les privilèges, l’attaquant devient « l’administrateur » de l’infrastructure. Il est en mesure d’exécuter des commandes arbitraires, de manipuler les configurations système, voire de déployer une porte dérobée. Ainsi, même si la faille initiale est maîtrisée, l’attaquant a toujours une carte dans sa manche.
Déni de service
Une fois le code malveillant installé, l’attaquant perturbe le fonctionnement de l’application à cause de calculs lourds. Il surcharge le serveur de requête, saturant ainsi les processeurs jusqu’au plantage. Résultat : l’application est hors service et rendue inaccessible par les clients.
Propagation de logiciels malveillants
L’injection de code est ici considérée comme un virus qui infecte l’application « patient zéro ». Dès qu’un utilisateur l’ouvre, il télécharge automatiquement un virus ou un rançongiciel.
Violations de la conformité
Les organisations soumises à des cadres réglementaires tels que le RGPD, la loi HIPAA ou la norme PCI DSS peuvent se voir infliger des amendes et des poursuites judiciaires si une attaque par injection de code entraîne une divulgation de données. Avec le RGPD par exemple, l’amende représente 4% du chiffre d’affaires mondial.
Types courants d’attaques par injection de code
L’injection de code peut prendre différentes formes. Les plus populaires d’entre eux sont :
Injection SQL
Il s’agit de la forme d’attaque par injection de code la plus courante, 50% des attaques visant les applications web. Elle consiste à manipuler les requêtes SQL pour modifier une base de données. Cela se traduit par l’insertion de caractères spéciaux dans la requête. Ici, les attaquants contournent les méthodes d’authentification classique pour accéder aux données.
Les principales cibles de ce type d’attaque sont les barres de recherche et les formulaires de connexion des applications. En 2011, une simple injection SQL a permis aux attaquants de dérober des données d’un million d’utilisateurs de Sony Pictures.
Injection Cross-Site Scripting (XSS)
Ici, l’attaquant injecte directement des scripts malveillants dans le site cible. Ce type d’attaque est efficace pour voler des jetons de session et des cookies. Le script est injecté via une URL ou un champ de commentaire ou encore les forums. Une fois cela fait, le navigateur de l’utilisateur le considère comme un code légitime et l’exécute. Le XSS figure dans le top 3 de l’OWASP depuis plus de dix ans.
Injection de commandes
L’application considère les entrées utilisateurs comme légitime et l’autorise à s’exécuter comme une commande par le système. En résulte un accès non autorisé aux fichiers, voire à une modification des données. Les applications de gestion de serveurs et les panneaux d’administration de routeurs sont les principales cibles de l’injection de commande. Bien qu’elle soit moins fréquente que l’injection injection, elle reste la plus létale puisque l’attaque peut aboutir à une remote code execution (RCE) totale.
Injection LDAP
L’injection LDAP cible les applications qui construisent des requêtes LDAP via les données saisies par l’utilisateur. Elle est similaire à l’injection SQL, à la différence qu’elle s’attaque directement aux services d’annuaire tels que Active Directory. L’attaquant insère des caractères pour manipuler les filtres de recherche LDAP. Son but est de passer outre l’authentification pour voler les données internes de l’organisation.
Meilleures pratiques contre l’injection de code
La prévention des attaques par injection de code adopte une approche multiforme combinant :
- Le renforcement du contrôle des entrées utilisateur en dressant une liste blanche. Cette liste permet à l’application de reconnaître les types de données autorisés et non autorisés. En plus d’être facile à configurer, la liste limite les capacités de l’attaquant à injecter du code malveillant.
- Mise en place de requêtes paramétrées pour éviter que les entrées utilisateur affectent directement la structure de la requête. Cette technique est disponible dans la plupart des langages de programmation et des systèmes de bases de données.
- Introduction du principe du moindre privilège : il part du principe qu’aucune personne ou application n’est fiable. Les applications disposent uniquement des accès nécessaires pour réaliser leurs tâches. Cette technique atténue la portée d’une attaque par injection. Une révision périodique des privilèges est aussi nécessaire.
- Instauration des procédures stockées pour servir de barrière entre les commandes de base de données et les entrées utilisateur. Cette méthode renforce le contrôle d’accès et empêche l’exécution de requêtes malveillantes. De plus, les procédures stockées allègent la charge d’analyse syntaxique et fluidifient l’exécution des commandes.
- Les audits de sécurité réguliers sont indispensables pour identifier les vulnérabilités au niveau des codes. Cela permet de mettre en place des mesures proactives. L’audit est généralement mené par une entité externe à l’organisation pour obtenir un avis impartial.
