Le projet de sécurité des applications Web en ligne (OWASP) aide les organisations à améliorer leur sécurité en proposant des directives basées sur des scénarios du monde réel et des projets open source dirigés par la communauté. Parmi les diverses menaces, l’OWASP considère l’injection de code comme un mécanisme de menace communément connu dans lequel les attaquants exploitent les failles de validation des entrées pour introduire du code malveillant dans une application.
Cet article explore comment une attaque par injection de code est effectuée, les types d’attaques et comment les équipes logicielles peuvent protéger leurs applications Web contre les failles d’injection.
Qu’est-ce que l’injection de code ?
Les acteurs de la menace tirent parti des vulnérabilités d’injection de code pour intégrer du code malveillant dans un code source, que l’application interprète et exécute. Lors de l’injection malveillante, les attaquants tirent parti du fait que ces systèmes construisent une partie d’un segment de code à l’aide de données externes tout en manquant de validation d’entrée suffisante. Le code malveillant est généralement conçu pour contrôler le flux de données, ce qui entraîne une perte de confidentialité et une disponibilité réduite des applications.
Les attaquants identifient les failles de validation des entrées des utilisateurs telles que : format de données, caractères autorisés, et le quantité de données attendues – et les utiliser comme base pour développer un code malveillant. L’OWASP classe les vulnérabilités d’injection au premier rang, avec leur détectabilité allant de facile à difficile. Bien que cela semble alarmant, avec les bonnes pratiques et une détection rapide, les vulnérabilités d’injection sont modérément difficiles à exploiter.
Injection de commande vs technique d’injection de code
Bien qu’elles soient souvent confuses, une vulnérabilité d’injection de code diffère de la vulnérabilité d’injection de commande. L’injection de code est un ensemble de techniques qui permettent à un utilisateur malveillant d’ajouter son propre code arbitraire à exécuter par l’application. L’injection de code est limitée aux systèmes et applications cibles puisque l’efficacité du code est confinée à un langage de programmation particulier.
D’autre part, l’injection de commandes consiste à tirer parti des vulnérabilités de l’application pour étendre les fonctionnalités de l’application afin qu’elle puisse exécuter des commandes arbitraires. Avec l’injection de commandes, les attaquants fournissent une entrée non sécurisée au shell du système, afin qu’ils puissent exécuter des commandes du système d’exploitation sur l’application vulnérable.
Comment fonctionne l’injection de code
Injection de code, également appelée Exécution de code à distance ou Évaluation des codes, implique la modification d’un exécutable ou d’un script contenant du code malveillant. Les pirates sondent d’abord l’application à la recherche de surfaces d’attaque pouvant accepter des données non fiables et les utilisent lors de l’exécution du code du programme. Il s’agit notamment d’entrées directes telles que les téléchargements de fichiers, les champs de formulaire ou d’autres sources de données telles que les cookies et les paramètres de chaîne de requête. L’introduction de code comprend généralement une concaténation directe de chaîne de caractères, la fonction PHP eval() ou son équivalent dans un autre langage. Un exploit réussi permet aux attaquants d’accéder à l’interpréteur côté serveur de l’application, après quoi les attaquants peuvent utiliser des appels système pour exécuter des commandes sur le serveur et pénétrer plus avant pour une exploitation plus approfondie.
Injection de code – Type d’attaques Exploits
Les types d’attaques par injection de code diffèrent selon le langage de programmation utilisé pour développer le code source de l’application et le code malveillant de l’attaquant. Cette section explore certaines catégories courantes de vulnérabilités/attaques par injection de code.
Injection de code côté client
Dans l’injection côté client, les pirates tirent parti des failles des applications où la validation des entrées est effectuée au niveau du navigateur avant que les données ne soient envoyées au serveur. De telles attaques incluent :
Injection de code SQL (SQLi)
SQL est largement utilisé dans les applications modernes pour créer des structures de données et interroger des ensembles de données. Les attaquants ciblent les détails de configuration vulnérables dans les systèmes de gestion de base de données relationnelle pour contrôler le serveur de base de données d’une application Web avec des instructions SQL malveillantes. Ces instructions modifient les requêtes SQL, permettant aux pirates d’accéder à des données cruciales, telles que les informations de connexion et les informations de configuration de l’application.
Injection de code Python
Les applications construites avec Python, les scripts qui acceptent les expressions des utilisateurs et évaluent leurs entrées peuvent être utilisés pour injecter du code malveillant. Considérons un simple script de calculatrice qui accepte et évalue les expressions à l’entrée de l’utilisateur :
compute = input('nYour expression? => ')
if not compute:
print ("No input")
else:
print ("Result =", eval(compute))Une expression mathématique régulière comme 5*6 renvoie un résultat attendu, 30. Dans le cas où le processus cible a des privilèges d’accès, sur une entrée malveillante telle que _import__(‘os’).system(‘rm -rf /’) dans le formulaire de saisie, tous les fichiers et répertoires situés dans le dossier du script sont supprimés.
Injection de code HTML/Script intersites
Les attaquants utilisent généralement des vulnérabilités d’injection de code HTML pour compromettre la façon dont les utilisateurs interagissent avec une application Web. Ce faisant, le pirate injecte du code HTML malveillant dans un site Web de confiance, qui exécute ensuite des scripts non fiables sur le navigateur de l’utilisateur final. Étant donné que le navigateur ne peut pas détecter le script malveillant, l’attaquant peut accéder aux jetons de session, aux cookies et à d’autres données cruciales que le navigateur conserve.
Injection de code côté serveur
L’injection de code côté serveur implique l’exploitation de failles dans les applications qui valident les entrées utilisateur côté serveur. Ceux-ci inclus:
Injection de code PHP
Certaines applications Web construites en PHP peuvent inclure une fonction dangereuse qui permet aux attaquants de contrôler tout ou partie du logiciel. Ces failles permettent aux pirates de changer le cours de l’exécution du code, en modifiant des parties d’une chaîne d’entrée. Le code ci-dessous traite la saisie de l’utilisateur à l’aide du eval php() fonction:
//The URL to access this https://codeinjection.crashtest-security.com/index.php?arg=1
$x = $_GET['arg'];
eval($x);Si l’application Web ne dispose pas d’une validation d’entrée suffisante, les pirates peuvent obtenir des informations sur la version PHP à l’aide de l’URL :
https://codeinjection.crashtest-security.com/index.php?arg=1; phpinfo()Les attaquants peuvent alors énumérer tous les services exécutés sur le serveur en demandant l’URL :
https://codeinjection.crashtest-security.com/index.php?arg=1; system('id')Injection Javascript côté serveur
Il est relativement facile d’insérer et d’utiliser son propre code Javascript sur un site Web soit en trouvant une vulnérabilité de script inter-sites, soit en incluant du code dans la barre d’adresse. Bien qu’il soit souvent utilisé dans la console du développeur comme mécanisme de débogage, les attaquants peuvent utiliser les vulnérabilités d’injection Javascript pour orchestrer des attaques afin de détourner les formulaires d’inscription, d’obtenir des informations d’identification et de compromettre la disponibilité du système.
Exemples d’attaques par injection de code
Alors que les attaques par injection de code sont courantes et que chaque organisation est connue pour être affectée par de telles vulnérabilités, voici quelques attaques par injection de code célèbres qui se sont produites récemment :
L’attaque du fantôme
Ghost Shell, un groupe d’activistes de la cybersécurité, a pu exposer plus de 30 millions de détails de compte en tirant parti de l’injection SQL et de scripts PHP mal configurés. Les piratages, qui ciblent le gouvernement et les établissements d’enseignement, impliquaient le téléchargement de nombreuses bases de données à partir de différents serveurs avec des mécanismes d’authentification défectueux. À l’aide d’outils d’analyse des ports, les pirates ont pu localiser des serveurs hébergeant des bases de données cruciales, puis ont téléchargé des données violées pour sensibiliser le public à une mauvaise configuration de la cybersécurité.
Violation de l’agence de la dette du gouvernement turc
RedHack, un groupe de hackers turcs a affirmé avoir pénétré le site Web de l’administration provinciale spéciale d’Istanbul (ios.gov.tr), apurant les dettes des gens envers les agences de services publics. Ils ont utilisé un simple script d’injection SQL pour contourner la page de connexion du site Web, leur donnant accès aux comptes d’administrateur et d’utilisateur final.
Attaques par injection sur des appareils d’architecture Harvard
Des chercheurs en cybersécurité de l’Université Cornell ont prouvé que les techniques de dépassement de mémoire tampon peuvent être utilisées pour injecter du code dans des périphériques embarqués qui reposent sur la conception de processeurs d’architecture Harvard. Ces appareils ont une mémoire limitée, ils ne peuvent donc traiter que de petits paquets. En utilisant diverses vulnérabilités du programme, les chercheurs ont prouvé qu’il était possible d’injecter du code permanent dans les capteurs afin qu’ils puissent prendre le contrôle total du processus hôte.
Comment détecter et empêcher les attaques par injection de code
Tant que les attaquants peuvent exploiter les paramètres de l’interpréteur côté serveur en envoyant des données malveillantes, presque toutes les interfaces d’entrée de données peuvent être un vecteur d’attaques par injection de code. Ces attaques sont courantes car les attaquants ont accès à des fuzzers et à des scanners qui détectent avec précision les failles d’injection de code. L’impact commercial de telles attaques peut varier de léger à grave en fonction des données exposées et des fonctions commerciales mises en œuvre par le logiciel. Par conséquent, il est de la plus haute importance de corriger les configurations de serveur incorrectes, d’éviter les sources de données non fiables et d’éliminer les autres vecteurs d’injection.
Meilleures pratiques pour empêcher les attaques par injection de code
Bien que les cas d’utilisation diffèrent selon les organisations, voici quelques bonnes pratiques pour éliminer les défauts d’injection de code dans les applications Web modernes.
- Utiliser la liste blanche pour la validation des entrées – La liste blanche est plus simple à configurer et donne aux équipes de sécurité un contrôle plus strict sur les données ou les types d’entrées que l’application peut traiter, contribuant ainsi à réduire le risque qu’un attaquant exécute un code malveillant.
- Encoder les sorties HTML – Les équipes de sécurité doivent tirer parti du codage de sortie contextuel pour convertir les entrées malveillantes en représentants plus sûrs, où les données des utilisateurs peuvent être affichées mais pas exécutées en tant que code.
- Utiliser un système de type statique pour imposer la séparation des langues – Avec les systèmes de type statique, les équipes peuvent développer des contrôles de contrôle déclaratifs sans la surcharge d’exécution supplémentaire.
- Tirez parti des requêtes paramétrées et des API basées sur des critères pour interpréter les chaînes de données utilisateur – Ceci est fait pour garantir que les API n’acceptent aucune valeur de chaîne autre que celles spécifiées. De plus, les requêtes paramétrées considèrent les entrées de commandes malveillantes comme une chaîne au lieu d’être une commande SQL.
- Évitez d’utiliser des fonctions dangereuses dans le code source – Il est important d’éviter toutes les constructions d’évaluation de code vulnérables lors du développement du code source. Les développeurs doivent plutôt utiliser des fonctionnalités sécurisées, dédiées et spécifiques à la langue pour traiter les entrées fournies par l’utilisateur.
- Utilisez le Http uniquement indicateur pour les cookies pour désactiver l’interaction de script côté client – Si le serveur définit l’indicateur HttpOnly sur chaque cookie qu’il crée, cela indique que le cookie ne doit pas être accessible du côté client. Les cookies ne peuvent donc être révélés à des tiers même en présence de défauts d’injection HTML.
- Utilisez les outils SCA pour rechercher et résoudre les problèmes – Les équipes doivent mettre en place des outils de vérification de code statique automatique pour rechercher et éliminer les vecteurs d’injection dans le code source.
- Éviter la sérialisation du code Javascript – Les développeurs utilisent la sérialisation du code pour réorganiser les données d’entrée dans un ensemble de fonctions et d’expressions régulières. Certaines versions des packages de sérialisation Javascript ne peuvent pas nettoyer correctement les caractères non fiables dans les expressions régulières. Il est recommandé d’éviter la sérialisation à moins que cela ne soit absolument nécessaire.
Sommaire
Les attaques par injection sont numéro un sur le Top 10 des vulnérabilités OWASP et sixième sur la liste Common Weakness Enumeration. Sans surprise, ces vulnérabilités sont très répandues, en particulier dans les applications héritées qui n’ont pas été conçues avec les meilleures pratiques de sécurité du code.
Les failles d’injection de code sont l’un des exploits les plus courants dans les attaques de logiciels malveillants, car elles peuvent être utilisées pour accéder à des…