Les codeurs vainquent la sécurité : Série "Partageons et apprenons" - Injections 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 .


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 notamment du genre de choses qui viennent à l'esprit lorsque l'on pense aux bases de données traditionnelles, à savoir des stocks détaillés d'informations sur des sujets aussi variés que les médicaments ou les films.
Jaap Karan Singh est un évangéliste du codage sécurisé, Chief Singh et cofondateur de Secure Code Warrior.

Secure Code Warrior est là pour vous aider à sécuriser le code tout au long du cycle de vie du développement logiciel et à créer une culture dans laquelle la cybersécurité est une priorité. Que vous soyez responsable AppSec, développeur, CISO ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre organisation à réduire les risques associés à un code non sécurisé.
Réservez une démonstrationJaap Karan Singh est un évangéliste du codage sécurisé, Chief Singh et cofondateur de Secure Code Warrior.


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 .

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 .

Cliquez sur le lien ci-dessous et téléchargez le PDF de cette ressource.
Secure Code Warrior est là pour vous aider à sécuriser le code tout au long du cycle de vie du développement logiciel et à créer une culture dans laquelle la cybersécurité est une priorité. Que vous soyez responsable AppSec, développeur, CISO ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre organisation à réduire les risques associés à un code non sécurisé.
Voir le rapportRéservez une démonstrationJaap Karan Singh est un évangéliste du codage sécurisé, Chief Singh et cofondateur de Secure Code Warrior.
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 .
Table des matières
Jaap Karan Singh est un évangéliste du codage sécurisé, Chief Singh et cofondateur de Secure Code Warrior.

Secure Code Warrior est là pour vous aider à sécuriser le code tout au long du cycle de vie du développement logiciel et à créer une culture dans laquelle la cybersécurité est une priorité. Que vous soyez responsable AppSec, développeur, CISO ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre organisation à réduire les risques associés à un code non sécurisé.
Réservez une démonstrationTéléchargerRessources pour vous aider à démarrer
Services professionnels - Accélérer grâce à l'expertise
L'équipe des services de stratégie de programme (PSS) de Secure Code Warriorvous aide à construire, améliorer et optimiser votre programme de codage sécurisé. Que vous partiez de zéro ou que vous affiniez votre approche, nos experts vous fournissent des conseils sur mesure.
Thèmes et contenu de la formation sur le code sécurisé
Notre contenu, à la pointe de l'industrie, évolue constamment pour s'adapter au paysage du développement logiciel en constante évolution, tout en gardant votre rôle à l'esprit. Les sujets abordés vont de l'IA à l'injection XQuery, et sont proposés pour une variété de rôles, des architectes et ingénieurs aux gestionnaires de produits et à l'assurance qualité. Découvrez en avant-première ce que notre catalogue de contenu a à offrir par sujet et par rôle.
Quêtes : Apprentissage de pointe pour permettre aux développeurs de garder une longueur d'avance et d'atténuer les risques.
Quests est une learning platform qui aide les développeurs à atténuer les risques liés à la sécurité des logiciels en améliorant leurs compétences en matière de codage sécurisé. Grâce à des parcours d'apprentissage, des défis pratiques et des activités interactives, elle permet aux développeurs d'identifier et de prévenir les vulnérabilités.
Ressources pour vous aider à démarrer
Vibe Coding va-t-il transformer votre base de code en une fête de fraternité ?
Le codage vibratoire est comme une fête de fraternité universitaire, et l'IA est la pièce maîtresse de toutes les festivités, le tonneau. C'est très amusant de se laisser aller, d'être créatif et de voir où votre imagination peut vous mener, mais après quelques barils, boire (ou utiliser l'IA) avec modération est sans aucun doute la solution la plus sûre à long terme.
La décennie des défenseurs : Secure Code Warrior Dixième anniversaire
Secure Code WarriorL'équipe fondatrice de SCW est restée soudée, dirigeant le navire à travers chaque leçon, chaque triomphe et chaque revers pendant une décennie entière. Nous nous développons et sommes prêts à affronter notre prochain chapitre, SCW 2.0, en tant que leaders de la gestion des risques pour les développeurs.