Les codeurs conquièrent la sécurité : Série "Partageons et apprenons" - Injection XXE

L'attaque par injection d'entité externe XML, parfois simplement abrégée en injection XXE, est relativement récente par rapport à certaines vulnérabilités classiques qui font encore parler d'elles des années après leur apparition. Mais elle est extrêmement populaire parmi les communautés de pirates informatiques et le devient de plus en plus au fur et à mesure qu'elle accumule les succès.

En fait, l'OWASP classe désormais l'injection XXE 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 dans les cyberattaques. Elle est simplement un peu plus récente et un peu moins bien comprise. Il est possible de l'éviter et, en fait, de l'arrêter complètement.

Dans cet épisode, vous apprendrez

• Comment les attaquants utilisent les injections XXE
• Pourquoi l'injection XXE est-elle dangereuse ?
• Techniques permettant d'éviter cette vulnérabilité.

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

La vulnérabilité de l'injection XXE peut se produire lorsqu'un utilisateur malveillant a la possibilité de soumettre un code XML. Il utilise cette capacité pour créer une référence à une entité externe. La référence externe et le code sont conçus pour contourner un analyseur XML avec des paramètres par défaut ou 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é correctement, il peut permettre aux processeurs XML d'accéder à des ressources distantes. Le plus souvent, les attaquants utilisent cette capacité pour sonder la structure interne d'un site web, lancer une attaque par déni de service en déclenchant de gros processus système essayant d'accéder à des ressources distantes, ou même décharger 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 comme les mots de passe ou les informations personnelles contenues dans la base de données XML.

Le code utilisé pour l'attaque est souvent assez simpliste, se contentant d'exploiter la fonctionnalité de l'entité. Par exemple, cela pourrait permettre à un pirate d'accéder au fichier du 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. Tout d'abord, il s'agit d'une vulnérabilité moins bien comprise à l'heure actuelle. Et les gains qu'un attaquant peut réaliser en l'exploitant sont considérables. D'une part, elle 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 parce qu'il envoie simplement du code XML dans un serveur qui est nettoyé par l'analyseur XML de confiance.

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

Élimination de la vulnérabilité de l'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é consiste simplement à ne pas activer cette fonctionnalité.

Mais même les analyseurs qui autorisent les DTD peuvent avoir cette fonctionnalité désactivée. En général, une instruction comme la suivante est nécessaire pour la bloquer complètement, mais vérifiez la documentation de votre framework local pour obtenir le code exact nécessaire.

factory.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true) ;

Conformément aux principes de sécurité, toutes les entrées utilisateur doivent être assainies 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 liste blanche et le filtrage fonctionnent, en raison du nombre croissant d'attaques par injection de XXE, il est recommandé de désactiver complètement la prise en charge de la DTD si cette fonctionnalité n'est pas nécessaire.

Plus d'informations sur XXE Injections

Pour en savoir plus, vous pouvez consulter ce que dit l'OWASP sur les attaques par injection XXE. Vous pouvez également mettre à l'épreuve vos nouvelles connaissances en matière de défense grâce à la démo gratuite de la plateforme Secure Code Warrior , qui forme les équipes de cybersécurité à devenir les meilleurs cyber-guerriers. Pour en savoir plus sur la manière de vaincre cette vulnérabilité et d'autres menaces, visitez le blogSecure Code Warrior .