コーダーがセキュリティを征服する:共有して学ぶシリーズ-XML インジェクション

Les attaques par injection XML sont de méchants petits exploits inventés par les pirates pour les aider à compromettre les systèmes hébergeant des bases de données XML. Il s'agit du genre de choses qui viennent à l'esprit lorsque l'on pense aux bases de données traditionnelles - des stocks détaillés d'informations sur n'importe quel sujet, des médicaments aux films. Certaines bases de données XML sont également utilisées pour vérifier les utilisateurs autorisés, de sorte que l'injection d'un nouveau code XML dans ces bases peut créer de nouveaux utilisateurs que le système hôte acceptera à partir de ce moment-là.

Pour qu'un attaquant puisse mettre en œuvre une injection XML, il faut qu'il y ait une application qui repose sur une base de données XML ou qui y accède au moins. Chaque fois que cela se produit et que l'entrée de l'utilisateur n'est pas correctement contrôlée, un nouveau code XML peut être ajouté à la base de données. Selon l'habileté de l'attaquant, l'ajout d'un nouveau code XML peut causer beaucoup de dégâts, voire donner accès à l'ensemble 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. En effet, bien qu'elles ciblent des types de bases de données différents, elles sont extrêmement similaires. Et heureusement, les solutions sont également similaires. En apprenant à vaincre un type d'attaque, vous aurez une longueur d'avance dans la prévention de l'autre.

Dans cet épisode, vous apprendrez

• Comment fonctionnent les injections XML
• Pourquoi ils sont si dangereux
• Comment vous pouvez mettre en place des défenses pour les arrêter complètement.

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

Les injections XML réussissent lorsqu'un utilisateur non autorisé est en mesure d'écrire un code XML et de l'insérer dans une base de données XML existante. Il suffit de deux choses pour que cela fonctionne : une application qui repose sur une base de données XML ou qui s'y connecte, et un chemin d'accès non sécurisé pour que l'attaquant puisse lancer son attaque.

Les injections XML réussissent presque toujours si l'entrée de l'utilisateur n'est pas assainie ou restreinte d'une autre manière avant d'être envoyée à un serveur pour y être traitée. Cela peut permettre aux attaquants d'écrire leur propre code, ou de l'injecter, à la fin de leur chaîne de requête normale. S'ils y parviennent, ils incitent le serveur à exécuter le code XML, ce qui lui permet d'ajouter ou de supprimer des enregistrements, voire de révéler l'intégralité d'une base de données.

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 quoi, d'un champ de recherche ou d'une page de connexion. Il 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 peut ajouter le code suivant après le champ du nom d'utilisateur ou du 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 sera créé avec un accès administrateur. Au moins, le nouvel utilisateur applique de bonnes règles de densité de mot de passe. Dommage qu'il s'agisse en fait d'un attaquant.

Les pirates n'ont pas nécessairement besoin de toujours réussir un coup de circuit comme celui-ci pour réussir avec les injections XML. En manipulant leurs requêtes et en enregistrant les différents messages d'erreur renvoyés par le serveur, ils peuvent être en mesure de déterminer la structure de la base de données XML. Ces informations peuvent être utilisées pour améliorer d'autres types d'attaques.  

Pourquoi les injections XML sont-elles si dangereuses ?

Le degré de dangerosité 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, dans le cas d'une base de données XML utilisée pour authentifier les utilisateurs, une injection XML peut permettre à un pirate d'accéder au système. Elle peut même lui permettre de devenir administrateur du réseau ciblé, ce qui est bien sûr une situation extrêmement dangereuse.

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

En règle générale, personne ne construit une base de données si les informations qui y sont stockées n'ont pas de valeur. Les pirates informatiques le savent, c'est pourquoi ils les prennent souvent pour cible. Si ces données comprennent des éléments tels que 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.  

Arrêter les attaques par injection de XML

Les injections XML sont assez courantes en raison du faible degré de difficulté de l'opération et de la prévalence des bases de données XML. Mais ces attaques existent depuis longtemps. Il existe donc plusieurs correctifs infaillibles qui les empêcheront de s'exécuter.

L'une des meilleures méthodes pour mettre fin aux attaques consiste à concevoir une application de manière à ce qu'elle n'utilise que des requêtes XML précompilées. Cela limite la fonctionnalité des requêtes à un sous-ensemble d'activités autorisées. Tout ce qui arrive avec des arguments supplémentaires ou des commandes qui ne correspondent pas aux fonctions de la requête précompilée ne sera tout simplement pas exécuté. Si vous ne souhaitez pas être aussi restrictif, vous pouvez également utiliser le paramétrage. Cela permet de limiter l'entrée de l'utilisateur à des types spécifiques de requêtes et de données, par exemple en n'utilisant que des nombres entiers. Tout ce qui n'entre pas dans ces paramètres est considéré comme non valide et entraîne 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 en cas d'échec de la requête, les applications devraient intercepter ces réponses et les remplacer par un message plus générique. Idéalement, vous souhaitez indiquer à l'utilisateur la raison de l'échec de la requête, sans lui donner d'informations sur la base de données elle-même. Si vous limitez ces messages personnalisés à quelques choix, les pirates ne seront pas en mesure de compiler des informations utiles à partir des requêtes qui ont échoué.

Les injections XML ont connu un grand succès lorsqu'elles ont été développées pour la première fois. Mais compte tenu de l'ancienneté de cette époque, nous pouvons aujourd'hui facilement mettre en place des défenses qui ne peuvent plus être franchies.

Plus d'informations sur XML Injections

Pour en savoir plus, vous pouvez consulter l'article de l'OWASP sur les injections XML. 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 .