L’injection de code est une vulnérabilité critique qui permet à un tiers d’exécuter le code sur le logiciel côté serveur. L’injection de langage d’expression est un type d’exécution de code à distance qui divulgue des données sensibles depuis le serveur. Le code distant exécute et affiche les variables, les mots de passe, les fonctions ou le code. Dans le pire des cas, il peut permettre à un attaquant de contrôler le serveur à distance.
Qu’est-ce que l’injection dans le langage d’expression ?
L’injection de langage d’expression est une vulnérabilité affectant les pages JavaServer (JSP), les pages Active Server (ASP) et d’autres langages d’expression hébergés sur un serveur Web. Ces langages sont des langages interprétés, de sorte que tout code envoyé au serveur est compilé pendant l’exécution de l’application, contrairement aux langages compilés standard avec des fichiers exécutables binaires. Dans un langage interprété, le code est compilé sur le serveur lorsqu’un utilisateur fait une demande de page.
Lorsqu’une application de langage d’expression (EL) est vulnérable à l’injection de langage d’expression, un attaquant envoie un code élaboré à l’application comme entrée, soit dans la chaîne de requête, soit dans un objet de forme. Le code est compilé au moment de l’exécution, et le code peut ensuite afficher des variables, des mots de passe et d’autres informations sensibles. Les vulnérabilités EL sont courantes dans les versions obsolètes des langages interprétés. Les applications traditionnelles doivent donc être testées avant d’être déployées en production. Après un événement critique, les organisations ont besoin de plans de reprise après sinistre pour corriger la divulgation des données et les exploitations.
Fonctionnement de l’injection de langage d’expression
Toute application exécutant un langage interprété doit supprimer le code et les caractères spéciaux de la saisie. Sans nettoyage des entrées, l’application accepte le code et l’exécute sur le serveur. La plupart des vulnérabilités d’injection EL impliquent JSP, nous utiliserons donc le code JSP dans l’exemple suivant. L’extrait ci-dessous est un exemple d’une seule ligne de code vulnérable à l’injection d’EL :
<spring:message code="${param['message']}" text=""/>
Dans cet exemple, l’attribut de code prend un paramètre contenant une chaîne. Si un attaquant injecte du code dans le paramètre, il est compilé et exécuté sur le serveur. Les utilisateurs ne voient pas ce code sur leur page Web locale, c’est pourquoi les attaquants utilisent des scripts courants pour détecter les vulnérabilités d’injection EL.
Vulnérabilités courantes entraînant l’injection du langage d’expression
Comme pour toute vulnérabilité à l’injection, la vulnérabilité à l’injection EL ne provient d’aucune validation d’entrée sur l’application serveur. Dans le même exemple que ci-dessus, la chaîne de message peut être une chaîne de caractères innocente, mais également un code. Au lieu d’envoyer une chaîne innocente, imaginez que l’utilisateur a envoyé les éléments suivants :
${"aaaa".toString().concat(T(java.lang.Runtime).getRuntime().exec('ls -l'))}
L'entrée ci-dessus tente d'exécuter la commande système « ls -l » sur le serveur. Cette commande répertorie les fichiers et les répertoires du répertoire actuel. Avec une liste de fichiers, un attaquant peut alors tenter d’envoyer une autre commande pour ouvrir et afficher le contenu d’un fichier dans sa fenêtre. Un fichier peut contenir des données sensibles telles que des mots de passe. À partir de là, le pirate pourrait potentiellement accéder au serveur et effectuer des actions malveillantes supplémentaires.
Détection de l’injection du langage d’expression
Les tests d’intrusion, à la fois en boîte blanche et en boîte noire, détecteront les vulnérabilités d’injection EL. Le test en boîte blanche est une méthode par laquelle les professionnels de la sécurité examinent le code pour détecter les vulnérabilités. Les entreprises fournissent le code aux examinateurs de sécurité, et les examinateurs identifient toutes les vulnérabilités de code dans un rapport. Il s’agit d’une approche proactive commune de la protection des données.
Les tests d’intrusion en boîte noire utilisent la même forme d’analyse et de détection des vulnérabilités qu’un attaquant. Les professionnels de la sécurité attaquent l’application sans connaître le code, de sorte que toute validation ou défense peut être testée. Le test de boîte grise est un mélange de tests de boîte noire et de boîte blanche, qui est souvent une méthode choisie pour les applications Web de test de pénétration.
Empêcher l’injection de langage d’expression
Le meilleur moyen de détecter les attaques par injection EL est de valider le code et de supprimer les entrées comportant des caractères spécifiques. Par exemple, la saisie d’un champ de nom ne doit pas contenir de caractères « <” or “> ». Les développeurs doivent utiliser des bibliothèques conçues pour détecter ces caractères et les supprimer ou supprimer l’entrée et afficher une erreur à l’utilisateur.
D’autres caractères peuvent également être malveillants. Sur une page JSP, les extraits de code commencent par les caractères « <%” characters and end with the “%> ». Ces caractères doivent être supprimés de la saisie. Les hackers effectuent de nombreuses combinaisons de code malveillant pour contourner la détection. Le meilleur moyen de le détecter est donc d’utiliser une bibliothèque conçue pour la validation des entrées. Les applications SIEM peuvent également détecter les exploits et fournir des analyses si votre application est une cible.
Conclusion
Les vulnérabilités d’injection EL doivent être traitées comme des problèmes de sécurité critiques. Faites toujours tester vos applications de langage interprété pour détecter les vulnérabilités d’injection et toute autre personne susceptible de divulguer des données sensibles. Les développeurs doivent utiliser des outils de validation pour détecter et arrêter l’injection d’EL, et les applications traditionnelles utilisant JSP et ASP doivent être étroitement surveillées pour détecter les attaques.
Pure Storage dispose de l’infrastructure de sécurité et de la surveillance des menaces nécessaires pour protéger vos applications contre les attaques de sécurité.
