Les développeurs à la conquête de la sécurité : Série Partage & Apprentissage - Injections XML

Les attaques par injection XML sont de petites failles malveillantes conçues par des pirates pour compromettre les systèmes hébergeant des bases de données XML. Cela inclut les types de données auxquels on pense naturellement en évoquant les bases de données traditionnelles : des stocks d'informations détaillées allant des médicaments aux films. Certains entrepôts de données XML servent également à vérifier les utilisateurs autorisés ; l'injection de nouveau code XML peut donc permettre de créer de nouveaux utilisateurs que le système hôte acceptera dès lors.

Pour qu'un attaquant puisse mettre en œuvre une injection XML, il faut une application qui s'appuie sur une base de données XML, ou qui y accède au moins. Chaque fois que cela se produit et que les entrées utilisateur ne sont pas correctement contrôlées, du nouveau code XML peut être ajouté à l'entrepôt de données. Selon les compétences de l'attaquant, l'ajout de nouveau code XML peut causer des dégâts considérables, voire donner accès à l'intégralité de la base de données.

En poursuivant votre lecture, vous découvrirez peut-être que l'injection XML est étroitement liée aux attaques par injection SQL que nous avons abordées précédemment. Bien qu'elles ciblent différents types de bases de données, elles sont extrêmement similaires. Heureusement, les correctifs le sont aussi. Apprendre à contrer un type d'attaque vous donnera une longueur d'avance pour prévenir l'autre.

Dans cet épisode, nous aborderons :

• Comment fonctionnent les injections XML
• Pourquoi elles sont si dangereuses
• Comment mettre en place des défenses pour les stopper complètement.

Comment les attaquants déclenchent-ils les injections XML ?

Les injections XML réussissent dès qu'un utilisateur non autorisé parvient à écrire du code XML et à l'insérer dans une base de données XML existante. Deux conditions suffisent : une application qui s'appuie sur une base de données XML (ou s'y connecte) et un canal de données non sécurisé permettant à l'attaquant de lancer son attaque.

Les injections XML réussissent presque toujours si les entrées utilisateur ne sont pas assainies ou restreintes avant d'être envoyées à un serveur pour traitement. Cela permet aux attaquants d'écrire leur propre code, ou de l'injecter, à la fin de leur chaîne de requête habituelle. Si l'opération réussit, le serveur est piégé et exécute le code XML, ce qui permet d'ajouter ou de supprimer des enregistrements, voire de révéler une base de données entière.

Les pirates mettent en œuvre une attaque par injection XML en ajoutant du code XML à une requête normale. Il peut s'agir de n'importe quel champ, d'une barre de recherche à une page de connexion. Cela peut même inclure des éléments tels que des cookies ou des en-têtes.

Par exemple, dans un formulaire d'inscription, un utilisateur pourrait ajouter le code suivant après le champ nom d'utilisateur ou mot de passe :

<user></user>
<role>administrator</role>
<username>John_Smith</username><password>Jump783!Tango@12</password>

Dans cet exemple, un nouvel utilisateur nommé John_Smith serait créé avec des droits d'administrateur. Au moins, le nouvel utilisateur respecte les règles de complexité des mots de passe. Dommage qu'il s'agisse en réalité d'un attaquant.

Les pirates n'ont pas toujours besoin de réussir un coup aussi spectaculaire pour que leurs injections XML soient efficaces. En manipulant leurs requêtes et en enregistrant les différents messages d'erreur renvoyés par le serveur, ils peuvent cartographier la structure de la base de données XML. Ces informations peuvent ensuite être utilisées pour renforcer d'autres types d'attaques.

Pourquoi les injections XML sont-elles si dangereuses ?

Le niveau de danger d'une attaque par injection XML dépend des informations stockées dans la base de données XML ciblée ou de la manière dont ces informations sont utilisées. Par exemple, si une base de données XML est utilisée pour authentifier les utilisateurs, une injection XML peut donner à un attaquant l'accès au système. Cela pourrait même lui permettre de devenir administrateur sur le réseau ciblé, ce qui constitue évidemment une situation extrêmement dangereuse.

Pour les injections XML visant des bases de données plus traditionnelles, le danger réside dans le vol d'informations, l'ajout de données incorrectes dans le stockage ou l'écrasement de données valides. Le code XML n'est pas très difficile à apprendre, et certaines commandes peuvent être extrêmement puissantes, permettant d'écraser des champs d'information entiers ou même d'afficher le contenu d'un entrepôt de données.

En règle générale, personne ne crée de base de données si les informations qui y sont stockées n'ont pas de valeur. Les pirates le savent, c'est pourquoi ils les ciblent souvent. Si ces données incluent des informations personnelles sur des employés ou des clients, leur compromission peut entraîner une perte de réputation, des conséquences financières, de lourdes amendes, voire des poursuites judiciaires.

Contrer les attaques par injection XML

Les injections XML sont relativement courantes en raison de leur facilité de mise en œuvre et de la prévalence des bases de données XML. Toutefois, ces attaques existent depuis longtemps. Il existe donc plusieurs solutions robustes pour les empêcher définitivement de se produire.

L'une des meilleures méthodes pour stopper ces attaques consiste à concevoir une application utilisant uniquement des requêtes XML précompilées. Cela limite les fonctionnalités des requêtes à un sous-ensemble d'activités autorisées. Toute tentative incluant des arguments ou des commandes supplémentaires ne correspondant pas aux fonctions précompilées ne sera tout simplement pas exécutée. Si vous préférez une approche moins restrictive, vous pouvez utiliser la paramétrisation. Cela limite les entrées utilisateur à des types de requêtes et de données spécifiques, comme l'utilisation exclusive d'entiers. Tout ce qui sort de ces paramètres est considéré comme invalide, provoquant l'échec de la requête.

Il est également judicieux d'associer des requêtes précompilées ou paramétrées à des messages d'erreur personnalisés. Au lieu de renvoyer les messages d'erreur descriptifs par défaut d'une requête ayant échoué, les applications doivent intercepter ces réponses et les remplacer par un message plus générique. Idéalement, vous devez informer l'utilisateur de l'échec de la requête sans pour autant divulguer d'informations sur la base de données elle-même. En limitant ces messages personnalisés à quelques choix, vous empêchez les pirates de collecter des informations utiles à partir des requêtes échouées.

Les injections XML étaient très efficaces lors de leur apparition. Mais compte tenu de leur ancienneté, nous pouvons aujourd'hui facilement mettre en place des défenses inviolables.

Plus d'informations sur les injections XML

Pour aller plus loin, vous pouvez consulter la documentation de l'OWASP sur les injections XML. Vous pouvez également mettre vos nouvelles connaissances défensives à l'épreuve avec la démo gratuite de la plateforme Secure Code Warrior, qui forme les équipes de cybersécurité à devenir des experts en la matière. Pour en savoir plus sur la neutralisation de cette vulnérabilité et d'une multitude d'autres menaces, visitez le blog de Secure Code Warrior.