Les codeurs vainquent la sécurité : Share & Learn Series - Injection XQuery
Les attaques par injection XQuery sont parfois considérées comme le petit frère des attaques par injection SQL, plus répandues. Leurs causes profondes sont similaires et les commandes que les attaquants exploitent pour les déclencher sont également très proches. Les attaques par injection XQuery ne peuvent toutefois se produire que lors d'une requête XPath portant sur des données XML. C'est pourquoi elles sont parfois appelées "injections XPath" ou simplement "attaques XPath", car c'est la méthode de livraison utilisée.
Une grande majorité de sites web utilisent des bases de données XML pour remplir des fonctions critiques telles que la conservation des identifiants de connexion des utilisateurs, des informations sur les clients, des informations sur l'identité personnelle et des données confidentielles ou sensibles, ce qui laisse aux attaques XQuery une empreinte d'attaque assez importante.
Dans cet épisode, vous apprendrez
- Comment les attaquants utilisent les injections XQuery
- Pourquoi les injections XQuery sont dangereuses
- Techniques permettant de corriger cette vulnérabilité.
Comment les attaquants déclenchent-ils une injection XQuery ?
Comme pour la plupart des langages informatiques, le code de XPath a été conçu pour être simple. En fait, XPath est un langage standard, et toutes les notations et déclarations syntaxiques sont inchangées quelle que soit l'application qui les utilise. Cela signifie que les commandes utilisées pour manipuler une requête XPath sont bien connues et peuvent même être automatisées.
À la base, une requête XPath est une simple déclaration qui indique à la base de données XML les informations à rechercher. Dans l'un des exemples les plus simples, elle est utilisée pour vérifier si un enregistrement d'utilisateur existe, puis pour récupérer ses identifiants de connexion. Le problème est qu'étant donné que les requêtes XPath comprennent une entrée utilisateur, les pirates peuvent manipuler la requête pour renvoyer des informations qui devraient être protégées.
Par exemple, lorsqu'il tente de contourner la sécurité de la connexion, un attaquant peut ajouter des variables à la fin de sa requête XPath, ce qui permet de contourner l'ensemble du processus. Un exemple pourrait ressembler à ceci :
//Employee[UserName/text()=anyone or 1=1 or a=a And Password/text()=doesnotmatter]
Ici, le champ Nom d'utilisateur peut correspondre à n'importe quel utilisateur grâce à la déclaration 1=1 ou a=a. Le champ mot de passe n'a pas d'importance, puisque seule la première partie de la requête doit être vraie.
Pourquoi l'injection XQuery est-elle dangereuse ?
L'une des principales raisons pour lesquelles les attaques par injection XQuery sont si dangereuses est qu'elles permettent aux attaquants de contourner la sécurité des connexions et des comptes. De plus, elles permettent de le faire de manière automatisée à l'aide d'un langage standard qui ne varie pas d'une application à l'autre. Les attaquants peuvent analyser automatiquement les sites web et les applications à la recherche de cette vulnérabilité et agir dès qu'elle est découverte. Si votre application est vulnérable, les attaquants la compromettront. En plus de compromettre la sécurité des comptes, les attaques XQuery peuvent également être utilisées pour exfiltrer des données. Par exemple, un attaquant pourrait transférer tous les enregistrements hors de la base de données XML.
Élimination des attaques par injection de XQuery
Comme pour les vulnérabilités similaires, l'un des principaux moyens de défense consiste simplement à ne pas faire confiance aux données saisies par l'utilisateur. Chaque fois qu'un utilisateur est en mesure de saisir des informations, qu'il interroge une base de données ou non, le processus doit être examiné de près. C'est un peu comme sécuriser les fenêtres et les portes d'un bâtiment physique, puisque ce sont les principaux moyens d'accès.
Pour la protection contre les injections XQuery, cela se fait en nettoyant l'entrée de l'utilisateur par le filtrage, ou en utilisant la validation de l'entrée de l'utilisateur par une liste blanche. Vous pouvez également utiliser une interface XPath paramétrée, similaire aux instructions préparées pour les requêtes SQL.
Enfin, veillez à appliquer le principe du moindre privilège à toutes les applications. Cela peut signifier la création d'un utilisateur avec des privilèges de lecture seule pour effectuer toutes les requêtes de l'application.
En utilisant ces techniques, il est possible d'arrêter toutes les tentatives d'injection de XQuery contre votre site web ou votre application.
Plus d'informations sur les injections XQuery
Pour en savoir plus, vous pouvez consulter ce que dit l'OWASP à propos des injections XQuery. Vous pouvez également mettre à l'épreuve vos nouvelles connaissances en matière de défense grâce à une démonstration 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 blog Secure Code Warrior.


Une grande majorité de sites web utilisent des bases de données XML pour remplir des fonctions critiques telles que la conservation des identifiants de connexion des utilisateurs, des informations sur les clients, des informations sur l'identité personnelle et des données confidentielles ou sensibles, ce qui laisse aux attaques XQuery une empreinte d'attaque assez importante.
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 XQuery sont parfois considérées comme le petit frère des attaques par injection SQL, plus répandues. Leurs causes profondes sont similaires et les commandes que les attaquants exploitent pour les déclencher sont également très proches. Les attaques par injection XQuery ne peuvent toutefois se produire que lors d'une requête XPath portant sur des données XML. C'est pourquoi elles sont parfois appelées "injections XPath" ou simplement "attaques XPath", car c'est la méthode de livraison utilisée.
Une grande majorité de sites web utilisent des bases de données XML pour remplir des fonctions critiques telles que la conservation des identifiants de connexion des utilisateurs, des informations sur les clients, des informations sur l'identité personnelle et des données confidentielles ou sensibles, ce qui laisse aux attaques XQuery une empreinte d'attaque assez importante.
Dans cet épisode, vous apprendrez
- Comment les attaquants utilisent les injections XQuery
- Pourquoi les injections XQuery sont dangereuses
- Techniques permettant de corriger cette vulnérabilité.
Comment les attaquants déclenchent-ils une injection XQuery ?
Comme pour la plupart des langages informatiques, le code de XPath a été conçu pour être simple. En fait, XPath est un langage standard, et toutes les notations et déclarations syntaxiques sont inchangées quelle que soit l'application qui les utilise. Cela signifie que les commandes utilisées pour manipuler une requête XPath sont bien connues et peuvent même être automatisées.
À la base, une requête XPath est une simple déclaration qui indique à la base de données XML les informations à rechercher. Dans l'un des exemples les plus simples, elle est utilisée pour vérifier si un enregistrement d'utilisateur existe, puis pour récupérer ses identifiants de connexion. Le problème est qu'étant donné que les requêtes XPath comprennent une entrée utilisateur, les pirates peuvent manipuler la requête pour renvoyer des informations qui devraient être protégées.
Par exemple, lorsqu'il tente de contourner la sécurité de la connexion, un attaquant peut ajouter des variables à la fin de sa requête XPath, ce qui permet de contourner l'ensemble du processus. Un exemple pourrait ressembler à ceci :
//Employee[UserName/text()=anyone or 1=1 or a=a And Password/text()=doesnotmatter]
Ici, le champ Nom d'utilisateur peut correspondre à n'importe quel utilisateur grâce à la déclaration 1=1 ou a=a. Le champ mot de passe n'a pas d'importance, puisque seule la première partie de la requête doit être vraie.
Pourquoi l'injection XQuery est-elle dangereuse ?
L'une des principales raisons pour lesquelles les attaques par injection XQuery sont si dangereuses est qu'elles permettent aux attaquants de contourner la sécurité des connexions et des comptes. De plus, elles permettent de le faire de manière automatisée à l'aide d'un langage standard qui ne varie pas d'une application à l'autre. Les attaquants peuvent analyser automatiquement les sites web et les applications à la recherche de cette vulnérabilité et agir dès qu'elle est découverte. Si votre application est vulnérable, les attaquants la compromettront. En plus de compromettre la sécurité des comptes, les attaques XQuery peuvent également être utilisées pour exfiltrer des données. Par exemple, un attaquant pourrait transférer tous les enregistrements hors de la base de données XML.
Élimination des attaques par injection de XQuery
Comme pour les vulnérabilités similaires, l'un des principaux moyens de défense consiste simplement à ne pas faire confiance aux données saisies par l'utilisateur. Chaque fois qu'un utilisateur est en mesure de saisir des informations, qu'il interroge une base de données ou non, le processus doit être examiné de près. C'est un peu comme sécuriser les fenêtres et les portes d'un bâtiment physique, puisque ce sont les principaux moyens d'accès.
Pour la protection contre les injections XQuery, cela se fait en nettoyant l'entrée de l'utilisateur par le filtrage, ou en utilisant la validation de l'entrée de l'utilisateur par une liste blanche. Vous pouvez également utiliser une interface XPath paramétrée, similaire aux instructions préparées pour les requêtes SQL.
Enfin, veillez à appliquer le principe du moindre privilège à toutes les applications. Cela peut signifier la création d'un utilisateur avec des privilèges de lecture seule pour effectuer toutes les requêtes de l'application.
En utilisant ces techniques, il est possible d'arrêter toutes les tentatives d'injection de XQuery contre votre site web ou votre application.
Plus d'informations sur les injections XQuery
Pour en savoir plus, vous pouvez consulter ce que dit l'OWASP à propos des injections XQuery. Vous pouvez également mettre à l'épreuve vos nouvelles connaissances en matière de défense grâce à une démonstration 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 blog Secure Code Warrior.

Les attaques par injection XQuery sont parfois considérées comme le petit frère des attaques par injection SQL, plus répandues. Leurs causes profondes sont similaires et les commandes que les attaquants exploitent pour les déclencher sont également très proches. Les attaques par injection XQuery ne peuvent toutefois se produire que lors d'une requête XPath portant sur des données XML. C'est pourquoi elles sont parfois appelées "injections XPath" ou simplement "attaques XPath", car c'est la méthode de livraison utilisée.
Une grande majorité de sites web utilisent des bases de données XML pour remplir des fonctions critiques telles que la conservation des identifiants de connexion des utilisateurs, des informations sur les clients, des informations sur l'identité personnelle et des données confidentielles ou sensibles, ce qui laisse aux attaques XQuery une empreinte d'attaque assez importante.
Dans cet épisode, vous apprendrez
- Comment les attaquants utilisent les injections XQuery
- Pourquoi les injections XQuery sont dangereuses
- Techniques permettant de corriger cette vulnérabilité.
Comment les attaquants déclenchent-ils une injection XQuery ?
Comme pour la plupart des langages informatiques, le code de XPath a été conçu pour être simple. En fait, XPath est un langage standard, et toutes les notations et déclarations syntaxiques sont inchangées quelle que soit l'application qui les utilise. Cela signifie que les commandes utilisées pour manipuler une requête XPath sont bien connues et peuvent même être automatisées.
À la base, une requête XPath est une simple déclaration qui indique à la base de données XML les informations à rechercher. Dans l'un des exemples les plus simples, elle est utilisée pour vérifier si un enregistrement d'utilisateur existe, puis pour récupérer ses identifiants de connexion. Le problème est qu'étant donné que les requêtes XPath comprennent une entrée utilisateur, les pirates peuvent manipuler la requête pour renvoyer des informations qui devraient être protégées.
Par exemple, lorsqu'il tente de contourner la sécurité de la connexion, un attaquant peut ajouter des variables à la fin de sa requête XPath, ce qui permet de contourner l'ensemble du processus. Un exemple pourrait ressembler à ceci :
//Employee[UserName/text()=anyone or 1=1 or a=a And Password/text()=doesnotmatter]
Ici, le champ Nom d'utilisateur peut correspondre à n'importe quel utilisateur grâce à la déclaration 1=1 ou a=a. Le champ mot de passe n'a pas d'importance, puisque seule la première partie de la requête doit être vraie.
Pourquoi l'injection XQuery est-elle dangereuse ?
L'une des principales raisons pour lesquelles les attaques par injection XQuery sont si dangereuses est qu'elles permettent aux attaquants de contourner la sécurité des connexions et des comptes. De plus, elles permettent de le faire de manière automatisée à l'aide d'un langage standard qui ne varie pas d'une application à l'autre. Les attaquants peuvent analyser automatiquement les sites web et les applications à la recherche de cette vulnérabilité et agir dès qu'elle est découverte. Si votre application est vulnérable, les attaquants la compromettront. En plus de compromettre la sécurité des comptes, les attaques XQuery peuvent également être utilisées pour exfiltrer des données. Par exemple, un attaquant pourrait transférer tous les enregistrements hors de la base de données XML.
Élimination des attaques par injection de XQuery
Comme pour les vulnérabilités similaires, l'un des principaux moyens de défense consiste simplement à ne pas faire confiance aux données saisies par l'utilisateur. Chaque fois qu'un utilisateur est en mesure de saisir des informations, qu'il interroge une base de données ou non, le processus doit être examiné de près. C'est un peu comme sécuriser les fenêtres et les portes d'un bâtiment physique, puisque ce sont les principaux moyens d'accès.
Pour la protection contre les injections XQuery, cela se fait en nettoyant l'entrée de l'utilisateur par le filtrage, ou en utilisant la validation de l'entrée de l'utilisateur par une liste blanche. Vous pouvez également utiliser une interface XPath paramétrée, similaire aux instructions préparées pour les requêtes SQL.
Enfin, veillez à appliquer le principe du moindre privilège à toutes les applications. Cela peut signifier la création d'un utilisateur avec des privilèges de lecture seule pour effectuer toutes les requêtes de l'application.
En utilisant ces techniques, il est possible d'arrêter toutes les tentatives d'injection de XQuery contre votre site web ou votre application.
Plus d'informations sur les injections XQuery
Pour en savoir plus, vous pouvez consulter ce que dit l'OWASP à propos des injections XQuery. Vous pouvez également mettre à l'épreuve vos nouvelles connaissances en matière de défense grâce à une démonstration 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 blog Secure 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 XQuery sont parfois considérées comme le petit frère des attaques par injection SQL, plus répandues. Leurs causes profondes sont similaires et les commandes que les attaquants exploitent pour les déclencher sont également très proches. Les attaques par injection XQuery ne peuvent toutefois se produire que lors d'une requête XPath portant sur des données XML. C'est pourquoi elles sont parfois appelées "injections XPath" ou simplement "attaques XPath", car c'est la méthode de livraison utilisée.
Une grande majorité de sites web utilisent des bases de données XML pour remplir des fonctions critiques telles que la conservation des identifiants de connexion des utilisateurs, des informations sur les clients, des informations sur l'identité personnelle et des données confidentielles ou sensibles, ce qui laisse aux attaques XQuery une empreinte d'attaque assez importante.
Dans cet épisode, vous apprendrez
- Comment les attaquants utilisent les injections XQuery
- Pourquoi les injections XQuery sont dangereuses
- Techniques permettant de corriger cette vulnérabilité.
Comment les attaquants déclenchent-ils une injection XQuery ?
Comme pour la plupart des langages informatiques, le code de XPath a été conçu pour être simple. En fait, XPath est un langage standard, et toutes les notations et déclarations syntaxiques sont inchangées quelle que soit l'application qui les utilise. Cela signifie que les commandes utilisées pour manipuler une requête XPath sont bien connues et peuvent même être automatisées.
À la base, une requête XPath est une simple déclaration qui indique à la base de données XML les informations à rechercher. Dans l'un des exemples les plus simples, elle est utilisée pour vérifier si un enregistrement d'utilisateur existe, puis pour récupérer ses identifiants de connexion. Le problème est qu'étant donné que les requêtes XPath comprennent une entrée utilisateur, les pirates peuvent manipuler la requête pour renvoyer des informations qui devraient être protégées.
Par exemple, lorsqu'il tente de contourner la sécurité de la connexion, un attaquant peut ajouter des variables à la fin de sa requête XPath, ce qui permet de contourner l'ensemble du processus. Un exemple pourrait ressembler à ceci :
//Employee[UserName/text()=anyone or 1=1 or a=a And Password/text()=doesnotmatter]
Ici, le champ Nom d'utilisateur peut correspondre à n'importe quel utilisateur grâce à la déclaration 1=1 ou a=a. Le champ mot de passe n'a pas d'importance, puisque seule la première partie de la requête doit être vraie.
Pourquoi l'injection XQuery est-elle dangereuse ?
L'une des principales raisons pour lesquelles les attaques par injection XQuery sont si dangereuses est qu'elles permettent aux attaquants de contourner la sécurité des connexions et des comptes. De plus, elles permettent de le faire de manière automatisée à l'aide d'un langage standard qui ne varie pas d'une application à l'autre. Les attaquants peuvent analyser automatiquement les sites web et les applications à la recherche de cette vulnérabilité et agir dès qu'elle est découverte. Si votre application est vulnérable, les attaquants la compromettront. En plus de compromettre la sécurité des comptes, les attaques XQuery peuvent également être utilisées pour exfiltrer des données. Par exemple, un attaquant pourrait transférer tous les enregistrements hors de la base de données XML.
Élimination des attaques par injection de XQuery
Comme pour les vulnérabilités similaires, l'un des principaux moyens de défense consiste simplement à ne pas faire confiance aux données saisies par l'utilisateur. Chaque fois qu'un utilisateur est en mesure de saisir des informations, qu'il interroge une base de données ou non, le processus doit être examiné de près. C'est un peu comme sécuriser les fenêtres et les portes d'un bâtiment physique, puisque ce sont les principaux moyens d'accès.
Pour la protection contre les injections XQuery, cela se fait en nettoyant l'entrée de l'utilisateur par le filtrage, ou en utilisant la validation de l'entrée de l'utilisateur par une liste blanche. Vous pouvez également utiliser une interface XPath paramétrée, similaire aux instructions préparées pour les requêtes SQL.
Enfin, veillez à appliquer le principe du moindre privilège à toutes les applications. Cela peut signifier la création d'un utilisateur avec des privilèges de lecture seule pour effectuer toutes les requêtes de l'application.
En utilisant ces techniques, il est possible d'arrêter toutes les tentatives d'injection de XQuery contre votre site web ou votre application.
Plus d'informations sur les injections XQuery
Pour en savoir plus, vous pouvez consulter ce que dit l'OWASP à propos des injections XQuery. Vous pouvez également mettre à l'épreuve vos nouvelles connaissances en matière de défense grâce à une démonstration 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 blog Secure 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
Vibe Coding : Guide pratique pour la mise à jour de votre stratégie AppSec pour l'IA
Regardez à la demande pour apprendre comment permettre aux responsables AppSec de devenir des facilitateurs de l'IA, plutôt que des bloqueurs, grâce à une approche pratique, axée sur la formation. Nous vous montrerons comment tirer parti de Secure Code Warrior (SCW) pour actualiser votre stratégie AppSec à l'ère des assistants de codage IA.
AI Coding Assistants : Un guide de navigation sécurisée pour la prochaine génération de développeurs
Les grands modèles linguistiques offrent des avantages irrésistibles en termes de rapidité et de productivité, mais ils présentent également des risques indéniables pour l'entreprise. Les garde-fous traditionnels ne suffisent pas à contrôler le déluge. Les développeurs ont besoin de compétences précises et vérifiées en matière de sécurité pour identifier et prévenir les failles de sécurité dès le début du cycle de développement du logiciel.
Ressources pour vous aider à démarrer
Série vidéo sur la sécurité AI/LLM : Tous les épisodes, mis à jour chaque semaine
Votre guide tout-en-un pour notre série vidéo de 12 semaines sur la sécurité de l'IA/LLM. Regardez chaque épisode, apprenez les concepts clés de la sécurité de l'IA et suivez la série chaque semaine.
SCW lance une série de vidéos gratuites sur la sécurité de l'IA/LLM à l'intention des développeurs
Voici notre série de vidéos gratuites sur la sécurité de l'IA/LLM en 12 semaines ! Découvrez les risques fondamentaux du codage assisté par l'IA et comment créer des applications plus sûres.
10 000+ activités d'apprentissage du code sécurisé : Une décennie de gestion des risques pour les développeurs
Célébration de plus de 10 000 activités d'apprentissage du code sécurisé et d'une décennie d'habilitation des développeurs à réduire les risques, à améliorer la qualité du code et à aborder en toute confiance le développement assisté par l'IA.