Blog

Les codeurs vainquent la sécurité : Share & Learn Series - Injection XQuery

Jaap Karan Singh
Publié le 28 février 2019

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.

Voir la ressource
Voir la ressource

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.

Vous souhaitez en savoir plus ?

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émonstration
Partager sur :
Auteur
Jaap Karan Singh
Publié le 28 février 2019

Jaap Karan Singh est un évangéliste du codage sécurisé, Chief Singh et cofondateur de Secure Code Warrior.

Partager sur :

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.

Voir la ressource
Voir la ressource

Remplissez le formulaire ci-dessous pour télécharger le rapport

Nous aimerions que vous nous autorisiez à vous envoyer des informations sur nos produits et/ou sur des sujets liés au codage sécurisé. Nous traiterons toujours vos données personnelles avec le plus grand soin et ne les vendrons jamais à d'autres entreprises à des fins de marketing.

Soumettre
Pour soumettre le formulaire, veuillez activer les cookies "Analytics". N'hésitez pas à les désactiver à nouveau une fois que vous aurez terminé.

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.

Accès aux ressources

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émonstration
Télécharger le PDF
Voir la ressource
Partager sur :
Vous souhaitez en savoir plus ?

Partager sur :
Auteur
Jaap Karan Singh
Publié le 28 février 2019

Jaap Karan Singh est un évangéliste du codage sécurisé, Chief Singh et cofondateur de Secure Code Warrior.

Partager sur :

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

Télécharger le PDF
Voir la ressource
Vous souhaitez en savoir plus ?

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écharger
Partager sur :
Centre de ressources

Ressources pour vous aider à démarrer

Plus d'articles
Centre de ressources

Ressources pour vous aider à démarrer

Plus d'articles