Semblables à injection SQL, les attaques par injection XPath peuvent survenir lorsqu'un site Web utilise des informations fournies par l'utilisateur pour construire une requête XPath pour récupérer des données XML. En envoyant des informations volontairement mal formées dans le site Web, un attaquant peut savoir comment les données XML sont structurées, ou accéder aux données auxquelles il ne peut normalement avoir accès. Il peut même être en mesure d'élever ses privilèges sur le site si les données XML sont utilisées pour l'authentification (par exemple, un fichier utilisateur basée sur XML).

L'interrogation de données XML est faite avec XPath, un type ensemble de mots clefs simples qui permettent à la requête XML de localiser un élément d'information. Comme SQL, vous pouvez spécifier certains attributs à trouver, et les modèles à utiliser. Lorsque vous utilisez XML pour un site web, il est courant d'accepter une certaine forme d'entrée sur la chaîne de requête pour identifier le contenu à localiser et à afficher sur la page. Cette entrée doit être nettoyée afin de vérifier qu'elle ne va pas polluer la requête XPath et retourner les données erronées.

XPath est un langage standard; sa syntaxe est toujours mise en oeuvre indépendamment ce qui signifie que l'attaque peut être automatisée. Il n'y a pas différents languages comme il en existe avec les bases de données SQL.

Parce qu'il n'y a pas de contrôle des niveau d'accès, il est possible d'obtenir le document en entier. On ne rencontrera pas les limitations qu'il peut y avoir dans les attaques par injection SQL.

Nous allons utiliser cet extrait xml pour les exemples.

<?xml version="1.0" encoding="utf-8"?>
 <Employees>
   <Employee ID="1">
      <FirstName>Arnold</FirstName>
      <LastName>Baker</LastName>
      <UserName>ABaker</UserName>
      <Password>SoSecret</Password>
      <Type>Admin</Type>
   </Employee>
   <Employee ID="2">
      <FirstName>Peter</FirstName>
      <LastName>Pan</LastName>
      <UserName>PPan</UserName>
      <Password>NotTelling</Password>
      <Type>User</Type>
   </Employee>
 </Employees>

Supposons que nous ayons un système d'authentification utilisateur sur une page Web qui utilise un fichier de données de ce genre pour se connecter . Une fois un nom d'utilisateur et mot de passe fournis le logiciel utilise XPath pour rechercher l'utilisateur:

VB:

Dim FindUserXPath as String
FindUserXPath = "//Employee[UserName/text()='" & Request("Username") & "' And 
       Password/text()='" & Request("Password") & "']"

C#:

String FindUserXPath;
FindUserXPath = "//Employee[UserName/text()='" + Request("Username") + "' And 
       Password/text()='" + Request("Password") + "']";

Avec un nom d'utilisateur et mot de passe normal cette requète XPath pourrait fonctionner, mais un attaquant peut envoyer un nom d'utilisateur et mot de passe mal former et obtenir un noeud XML sélectionné sans connaître le nom d'utilisateur ou mot de passe, comme ceci:

Username: blah' or 1=1 or 'a'='a
Password: blah
.
FindUserXPath devient
//Employee[UserName/text()='blah' or 1=1 or 'a'='a' And Password/text()='blah']

Logiquement, cela est équivalent à:

  //Employee[(UserName/text()='blah' or 1=1) or  ('a'='a' And Password/text()='blah')]

Dans ce cas, seule la première partie de l'expression XPath doit être vrai. La partie mot de passe devient inutile, et la partie UserName correspond à tous les salariés en raison de la condition “1 = 1”.

Tout comme l'injection SQL, afin de vous protéger, vous devez échapper les guillemets simples (ou doubles guillemets) si votre application les utilise.

VB:

Dim FindUserXPath as String
FindUserXPath = "//Employee[UserName/text()='" & Request("Username").Replace("'", "'") & "' And 
       Password/text()='" & Request("Password").Replace("'", "'") & "']"

C#:

String FindUserXPath;
FindUserXPath = "//Employee[UserName/text()='" + Request("Username").Replace("'", "'") + "' And 
       Password/text()='" + Request("Password").Replace("'", "'") + "']";

Une autre (et meilleure) protection est d'utiliser une expression XPath compilée Les expressions XPaths précompilées sont déjà prédéfinie avant que le programme les exécute, au lieu de les créer à la volée, après que l'entrée de l'utilisateur a été ajouté à la chaîne. Il s'agit d'une meilleure solution parce que vous n'avez pas à vous soucier d'oublier un caractère qui aurait dû être échappé.