Les codeurs à la conquête de la sécurité : série Share & Learn - XQuery Injection

Les attaques par injection XQuery sont parfois considérées comme le petit frère des attaques les plus répandues. Attaques par injection SQL. Ils ont des causes profondes similaires, et les commandes que les attaquants exploitent pour les déclencher sont également très proches. C'est juste que les attaques par injection XQuery ne peuvent se produire que lors d'une requête XPath pour des données XML. Pour cette raison, elles sont parfois appelées XPath Injection ou simplement attaques XPath, car c'est la méthode de diffusion utilisée.

La grande majorité des sites Web utilisent des bases de données XML pour exécuter des fonctions critiques telles que la conservation des informations de connexion des utilisateurs, des informations sur les clients, des informations d'identité personnelle et des données confidentielles ou sensibles, laissant aux attaques XQuery une empreinte d'attaque assez importante.

Dans cet épisode, nous allons apprendre :

• 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 la plupart des langages informatiques, le code de XPath a été conçu dans un souci de simplicité. En fait, XPath est un langage standard, et toutes les notations et instructions de syntaxe restent 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 instruction simple qui indique à la base de données XML quelles informations rechercher. Dans l'un des exemples les plus simplistes, il est utilisé pour vérifier si un enregistrement utilisateur existe, puis pour récupérer ses informations de connexion. Le problème est que, comme les requêtes XPath incluent des entrées utilisateur, les pirates peuvent manipuler la requête pour renvoyer des informations qui doivent être protégées.

Par exemple, lorsqu'il essaie de contourner la sécurité de connexion, un attaquant peut ajouter des variables à la fin de sa requête XPath qui contournent l'ensemble du processus. Un exemple pourrait ressembler à ceci :

//Employé [Nom d'utilisateur/texte () = n'importe qui ou 1=1 ou a=a Et mot de passe/texte () = peu importe]

Ici, le champ Nom d'utilisateur est conçu pour correspondre à n'importe quel utilisateur en raison de l'instruction 1=1 ou a=a. Le champ du mot de passe n'aura même pas d'importance, car 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. Et ils permettent de le faire de manière automatisée en utilisant un langage standard qui ne varie pas d'une application à l'autre. Les attaquants peuvent analyser automatiquement les sites Web et les applications pour détecter 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 XQuery

Comme pour les vulnérabilités similaires, l'une des principales défenses consiste simplement à ne pas se fier aux entrées des utilisateurs. Chaque fois qu'un utilisateur est en mesure de saisir des informations, qu'il effectue une requête dans la base de données ou non, le processus doit être examiné de près. Ce n'est pas sans rappeler la sécurisation des fenêtres et des portes d'un bâtiment physique, car ce sont les principaux moyens d'accès.

Pour la protection contre les injections XQuery, cela se fait en nettoyant les entrées utilisateur par le biais d'un filtrage, ou en utilisant la validation des entrées utilisateur sur 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 minimum de privilège à toutes les applications. Cela peut impliquer la création d'un utilisateur doté de privilèges en lecture seule pour effectuer toutes les requêtes d'application.

En utilisant ces techniques, il est possible d'arrêter toutes les tentatives d'injection XQuery effectuées 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 à un démo gratuite de la plateforme Secure Code Warrior, qui forme les équipes de cybersécurité à devenir les meilleurs cyberguerriers. Pour en savoir plus sur les moyens de neutraliser cette vulnérabilité et consulter une galerie d'autres menaces présentées par des escrocs, rendez-vous sur Code sécurisé Guerrier bloguer.