コーダーがセキュリティを征服:共有して学ぶシリーズ-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.