Les développeurs face à la sécurité : série Partage & Apprentissage - 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. Elles ont des causes profondes similaires et les commandes que les attaquants exploitent pour les déclencher sont également très proches. La seule différence est que les attaques par injection XQuery ne peuvent se produire que lors d'une requête XPath pour des données XML. C'est pourquoi on les appelle parfois injections XPath ou simplement attaques XPath, car il s'agit de la méthode de diffusion utilisée.

Une immense majorité de sites web utilisent des bases de données XML pour effectuer des fonctions critiques telles que le stockage des identifiants de connexion, des informations clients, des données personnelles et des informations confidentielles ou sensibles, ce qui confère aux attaques XQuery une surface d'attaque particulièrement étendue.

Dans cet épisode, nous aborderons :

• Comment les attaquants utilisent les injections XQuery
• Pourquoi les injections XQuery sont dangereuses
• Techniques pour corriger cette vulnérabilité.

Comment les attaquants déclenchent-ils une injection XQuery ?

Comme pour la plupart des langages informatiques, le code XPath a été conçu pour être simple. En fait, XPath est un langage standard, et toutes les notations et syntaxes 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 simples, elle est utilisée pour vérifier si un enregistrement utilisateur existe, puis pour récupérer ses identifiants 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 devraient être protégées.

Par exemple, pour tenter de contourner la sécurité de connexion, un attaquant peut ajouter des variables à la fin de sa requête XPath afin de court-circuiter l'ensemble du processus. Voici un exemple possible :

//Employee[UserName/text()=anyone or 1=1 or a=a And Password/text()=doesnotmatter]

Ici, le champ Nom d'utilisateur est forcé de correspondre à n'importe quel utilisateur grâce à l'instruction 1=1 ou a=a. Le champ mot de passe n'a même plus 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. De plus, elles permettent de le faire de manière automatisée en utilisant un langage standard qui ne varie pas selon l'application. Les attaquants peuvent scanner 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. Au-delà de la compromission de la sécurité des comptes, les attaques XQuery peuvent également être utilisées pour l'exfiltration de données. Par exemple, un attaquant pourrait transférer tous les enregistrements hors de la base de données XML.

Éliminer les attaques par injection XQuery

Comme pour les vulnérabilités similaires, une défense clé consiste simplement à ne pas faire confiance aux entrées utilisateur. Chaque fois qu'un utilisateur est en mesure de saisir des informations, qu'il effectue une requête en base de données ou non, le processus doit être examiné. C'est un peu comme sécuriser les portes et les fenêtres d'un bâtiment physique, car ce sont les principaux moyens par lesquels les gens peuvent accéder.

Pour la protection contre l'injection XQuery, cela se fait en assainissant les entrées utilisateur par le filtrage, ou en utilisant une validation d'entrée sur liste blanche. Vous pouvez également utiliser une interface XPath paramétrée, similaire aux requêtes préparées pour le SQL.

Enfin, assurez-vous d'appliquer le principe du moindre privilège à toutes les applications. Cela peut signifier créer 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 XQuery dirigées contre votre site web ou votre application.

Plus d'informations sur les injections XQuery

Pour aller plus loin, vous pouvez consulter ce que l'OWASP dit au sujet des injections XQuery. Vous pouvez également mettre vos nouvelles connaissances en matière de défense à l'épreuve avec une démo gratuite de la plateforme Secure Code Warrior, qui forme les équipes de cybersécurité à devenir les ultimes cyber-guerriers. Pour en savoir plus sur la façon de contrer cette vulnérabilité et une galerie d'autres menaces, visitez le blog de Secure Code Warrior.