Les codeurs à la conquête de la sécurité : série Share & Learn - Injections XML

Les attaques par injection XML sont de vilains petits exploits inventés par des pirates informatiques pour les aider à compromettre les systèmes hébergeant des bases de données XML. Cela inclut le genre de choses qui viennent à l'esprit lorsque l'on pense aux bases de données traditionnelles, à savoir des magasins détaillés d'informations sur tout, des médicaments aux films. Certaines banques de données XML sont également utilisées pour vérifier la présence d'utilisateurs autorisés. Par conséquent, l'injection d'un nouveau code XML dans celles-ci peut créer de nouveaux utilisateurs que le système hôte acceptera à partir de ce moment.

Pour qu'un attaquant puisse implémenter une injection XML, il doit exister 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 de l'utilisateur ne sont pas correctement vérifiées, un nouveau code XML peut être ajouté à la banque de données. Selon les compétences de l'attaquant, l'ajout d'un nouveau code XML peut faire de gros dégâts, 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. En effet, même s'ils ciblent différents types de bases de données, ils sont extrêmement similaires. Et heureusement, les correctifs sont également similaires. En apprenant à vaincre un type d'attaque, vous aurez une longueur d'avance lorsque vous vous efforcerez de prévenir l'autre.

Dans cet épisode, nous allons apprendre :

• Comment fonctionnent les injections XML
• Pourquoi sont-ils si dangereux
• Comment 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 chaque fois qu'un utilisateur non autorisé est capable d'écrire du code XML et de l'insérer dans une base de données XML existante. Cela ne nécessite que deux éléments pour fonctionner : une application qui s'appuie sur une base de données XML ou s'y connecte et un chemin de données non sécurisé permettant à l'attaquant de lancer son attaque.

Les injections XML sont presque toujours couronnées de succès si les entrées de l'utilisateur ne sont pas nettoyées ou restreintes avant d'être envoyées à un serveur pour traitement. Cela peut permettre aux attaquants d'écrire leur propre code, ou de l'injecter, à la fin de leur chaîne de requête normale. En cas de succès, cela incite le serveur à exécuter le code XML, ce qui lui permet d'ajouter ou de supprimer des enregistrements, ou même de révéler une base de données complète.

Les pirates mettent en œuvre une attaque par injection XML en ajoutant du code XML à une requête normale. Cela peut aller d'un champ de recherche à 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>administrateur</role>
<username>John_Smith Jump783 !</username> <password> Tango @12</password>

Dans cet exemple, un nouvel utilisateur nommé John_Smith serait créé avec un accès administrateur. Au moins, le nouvel utilisateur utilise de bonnes règles de densité de mots de passe. Dommage qu'il s'agisse en fait d'un attaquant.

Les pirates informatiques n'ont pas nécessairement besoin de toujours effectuer un tel home run pour réussir leurs 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 cartographier la structure de la base de données XML. Et ces informations peuvent être utilisées pour améliorer d'autres types d'attaques.

Pourquoi les injections XML sont-elles si dangereuses ?

Le niveau de danger associé à 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 attaquant d'accéder au système. Cela pourrait même leur permettre de devenir administrateur sur le réseau ciblé, ce qui est bien sûr une situation extrêmement dangereuse.

En ce qui concerne les injections XML prélevées sur des bases de données plus traditionnelles, le danger réside dans le fait que ces informations soient volées, que des données incorrectes soient ajoutées au magasin ou que de bonnes données soient remplacées. Le code XML n'est pas très difficile à apprendre, et certaines commandes peuvent être extrêmement puissantes, écrasant des champs d'informations entiers ou même affichant le contenu d'une banque de données.

En général, personne ne crée de base de données à moins que les informations qui y sont stockées n'aient de valeur. Les pirates informatiques le savent, c'est pourquoi ils les ciblent souvent. Si ces données contiennent 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 ou même des poursuites judiciaires.

Stopper les attaques par injection XML

Les injections XML sont assez courantes en raison du faible degré de difficulté à en réaliser une et de la prévalence des bases de données XML. Mais ces attaques existent depuis longtemps. En tant que tels, il existe plusieurs correctifs irréfutables qui les empêcheront de s'exécuter.

L'une des meilleures méthodes pour stopper les attaques consiste à concevoir une application qui n'utilise que des requêtes XML précompilées. Cela limite la fonctionnalité des requêtes à un sous-ensemble d'activités autorisé. Tout ce qui arrive avec des arguments ou des commandes supplémentaires qui ne correspondent pas aux fonctions de requête précompilées ne s'exécutera tout simplement pas. Si vous ne voulez pas être aussi restrictif, vous pouvez également utiliser le paramétrage. Cela limite la saisie par l'utilisateur à des types spécifiques de requêtes et de données, par exemple en utilisant uniquement des entiers. Tout ce qui ne correspond pas à 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 provenant d'une requête échouée, les applications devraient intercepter ces réponses et les remplacer par un message plus générique. Idéalement, vous devriez indiquer à un utilisateur pourquoi la requête a échoué, mais ne pas 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 pourront pas compiler de reconnaissance utile à partir de requêtes échouées.

Les injections XML ont connu un grand succès lors de leur développement initial. Mais étant donné que c'était il y a longtemps, nous pouvons aujourd'hui facilement construire des défenses qui ne peuvent plus être violées.

Plus d'informations sur les injections XML

Pour en savoir plus, vous pouvez consulter l'OWASP écrire sur Injections XML. 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.