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
Évaluation comparative des compétences en matière de sécurité : Rationalisation de la conception sécurisée dans l'entreprise
Le mouvement "Secure-by-Design" (conception sécurisée) est l'avenir du développement de logiciels sécurisés. Découvrez les éléments clés que les entreprises doivent garder à l'esprit lorsqu'elles envisagent une initiative de conception sécurisée.
DigitalOcean réduit sa dette de sécurité avec Secure Code Warrior
L'utilisation par DigitalOcean de la formation Secure Code Warrior a considérablement réduit la dette de sécurité, permettant aux équipes de se concentrer davantage sur l'innovation et la productivité. L'amélioration de la sécurité a renforcé la qualité des produits et l'avantage concurrentiel de l'entreprise. À l'avenir, le score de confiance SCW les aidera à améliorer leurs pratiques de sécurité et à continuer à stimuler l'innovation.
Ressources pour vous aider à démarrer
Sécurité réactive contre sécurité préventive : La prévention est un meilleur remède
L'idée d'apporter une sécurité préventive aux codes et systèmes existants en même temps qu'aux applications plus récentes peut sembler décourageante, mais une approche "Secure-by-Design", mise en œuvre en améliorant les compétences des développeurs, permet d'appliquer les meilleures pratiques de sécurité à ces systèmes. C'est la meilleure chance qu'ont de nombreuses organisations d'améliorer leur sécurité.
Les avantages de l'évaluation des compétences des développeurs en matière de sécurité
L'importance croissante accordée au code sécurisé et aux principes de conception sécurisée exige que les développeurs soient formés à la cybersécurité dès le début du cycle de développement durable, et que des outils tels que le Trust Score de Secure Code Warriorles aident à mesurer et à améliorer leurs progrès.
Assurer le succès des initiatives de conception sécurisée de l'entreprise
Notre dernier document de recherche, Benchmarking Security Skills : Streamlining Secure-by-Design in the Enterprise est le résultat d'une analyse approfondie d'initiatives réelles de conception sécurisée au niveau de l'entreprise, et de l'élaboration d'approches de meilleures pratiques basées sur des conclusions fondées sur des données.
Plongée en profondeur : Naviguer dans la vulnérabilité critique de CUPS dans les systèmes GNU-Linux
Découvrez les derniers défis de sécurité auxquels sont confrontés les utilisateurs de Linux en explorant les récentes vulnérabilités de haute sévérité dans le système d'impression commun d'UNIX (CUPS). Apprenez comment ces problèmes peuvent conduire à une potentielle exécution de code à distance (RCE) et ce que vous pouvez faire pour protéger vos systèmes.