Les codeurs conquièrent la sécurité : série Share & Learn - XXE Injection

L'attaque par injection d'entités externes XML, parfois simplement abrégée en injection XXE, est relativement récente par rapport à certaines des vulnérabilités classiques qui font encore leur apparition des années après leur création. Mais il est extrêmement populaire parmi les communautés de hackers en ce moment, et il gagne encore en popularité au fur et à mesure qu'il accumule des succès.

En fait, l'OWASP classe désormais XXE Injection parmi les dix principales vulnérabilités que les sites doivent surveiller et contre lesquelles ils doivent se défendre activement. Mais ne vous inquiétez pas, l'injection XXE n'est pas plus puissante que les autres exploits déployés lors de cyberattaques. C'est juste un peu plus récent et un peu moins compris. Elle peut être évitée et même complètement arrêtée.

Dans cet épisode, nous allons apprendre :

• Comment les attaquants utilisent les injections XXE
• Pourquoi l'injection XXE est dangereuse
• Techniques permettant de prévenir cette vulnérabilité.

Comment les attaquants déclenchent-ils une injection XXE ?

La vulnérabilité d'injection XXE peut survenir lorsqu'un utilisateur malveillant est autorisé à soumettre du code XML. Ils utilisent cette capacité pour créer une référence à une entité externe. La référence externe et le code sont conçus pour passer outre un analyseur XML avec des paramètres par défaut ou un analyseur avec des paramètres faiblement configurés.

L'attaquant exploite le fait que la norme XML définit le concept d'entité comme une unité de stockage d'un certain type, mais que ce stockage peut être externe ou interne. Utilisée correctement, elle peut permettre aux processeurs XML d'accéder à des ressources distantes. Le plus souvent, les attaquants utilisent cette capacité pour effectuer des tâches telles que sonder la structure interne d'un site Web, lancer une attaque par déni de service en déclenchant de grands processus système tentant d'accéder à des ressources distantes, ou même transférer des données d'un hôte local vers un hôte distant qu'ils contrôlent », ce qui en fait une bonne technique pour exfiltrer des données importantes telles que les mots de passe ou les informations personnelles contenues dans la base de données XML.

Le code réel impliqué dans l'attaque est souvent assez simpliste, exploitant simplement les fonctionnalités de l'entité. Par exemple, cela pourrait permettre à un pirate informatique d'accéder au fichier de mot de passe principal :

< ! ENTITY hackwithxxe SYSTEM file : ///etc/password>

Pourquoi l'injection XXE est-elle dangereuse ?

Il y a plusieurs raisons pour lesquelles les attaques par injection XXE sont si dangereuses et si répandues. D'une part, il s'agit d'une vulnérabilité moins connue à l'heure actuelle. Et les gains qu'un attaquant peut réaliser en l'exploitant sont considérables. D'une part, il peut permettre à des attaquants persistants de cartographier lentement tous les chemins d'un réseau interne ou même de scanner les ports. Bien que cela puisse prendre un certain temps, il n'y a pratiquement aucune chance que l'activité d'un pirate soit découverte par des défenses actives sur le réseau cible, car il envoie simplement du code XML à un serveur qui est autorisé par l'analyseur XML de confiance.

Une fois cartographiés, les attaquants peuvent utiliser les mêmes techniques d'injection XXE pour capturer tous les fichiers dont ils ont besoin, soit en volant directement des informations, soit en compromettant des informations d'identification utilisateur valides et en les utilisant pour des attaques secondaires. Enfin, les attaquants qui veulent simplement faire du bruit et être malveillants peuvent notamment déclencher des attaques par déni de service, ordonner à l'application d'essayer d'accéder à des ressources distantes conçues pour enliser le système.

Élimination de la vulnérabilité d'injection XXE

En raison de l'augmentation rapide des attaques par injection XXE, de nombreux analyseurs XML commencent à désactiver complètement par défaut les entités externes, parfois appelées DTD. Pour ceux-là, la clé est simplement de ne pas activer cette fonctionnalité.

Mais même les analyseurs qui autorisent les DTD peuvent désactiver cette fonctionnalité. En général, une instruction comme celle-ci sera nécessaire pour le bloquer complètement, mais consultez la documentation de votre framework local pour obtenir le code exact requis.

Factory.setFeature (» http://apache.org/xml/features/disallow-doctype-decl «, vrai) ;

Conformément aux principes de sécurité, toutes les entrées des utilisateurs doivent être nettoyées et validées à l'aide de filtres applicables à l'ensemble de l'application. N'oubliez pas d'inclure les paramètres GET et POST, les en-têtes HTTP et les cookies. Vous pouvez également créer une liste blanche de DTD et de commandes spécifiques que vous souhaitez que l'analyseur traite, et interdire tout le reste.

Bien que la mise en liste blanche et le filtrage fonctionnent, en raison du nombre croissant d'attaques par injection XXE, il est toujours recommandé de désactiver complètement le support DTD si la fonctionnalité n'est pas requise.

Plus d'informations sur les injections XXE

Pour en savoir plus, vous pouvez consulter ce que dit l'OWASP à propos de Attaques par injection XXE. Vous pouvez également mettre à l'épreuve vos nouvelles connaissances en matière de défense grâce au démo gratuite de la plateforme Secure Code Warrior, qui forme les équipes de cybersécurité à devenir les meilleurs cyberguerriers. Pour en savoir plus sur les moyens de neutraliser cette vulnérabilité et consulter une galerie d'autres menaces présentées par des escrocs, rendez-vous sur Blog Secure Code Warrior.