Table of Contents

testing_guide

Résumé

On parle de tests d'injection XML lorsque on essaye d'injecter un document XML dans l'application: si l'analyseur XML ne parvient pas à faire une validation des données le test sera positif.

Description

Dans cette section, nous décrivons un exemple pratique d'injection XML: en premier lieu, un style de communication XML sera défini, et ses principes de fonctionnement expliqués. Puis, nous décrirons la méthode de découverte dans lequel on cherche à insérer les métacaractères XML. Une fois que la première étape est accomplie, le testeur devra récupérer les informations sur la structure XML, de sorte qu'il sera possible d'essayer d'injecter des données XML et les balises (Tag injection).

Test boîte noire

Supposons qu'il y ait une application web en utilisant un style de communication XML afin de pouvoir procéder à l'enregistrement de l'utilisateur. Cela se fait en créant et en ajoutant un nœud <userr> dans un fichier XMLDB. Supposons que le fichier XMLDB est comme ce qui suit: 

<?xml version="1.0" encoding="ISO-8859-1"?> 
<users> 
       <user> 
               <username>gandalf</username> 
               <password>!c3</password> 
               <userid>0</userid>
               <mail>gandalf@middleearth.com</mail>
       </user> 
       <user> 
               <username>Stefan0</username> 
               <password>w1s3c</password> 
               <userid>500</userid>
               <mail>Stefan0@whysec.hmm</mail>
       </user> 
</users>

Lorsqu'un utilisateur s'enregistre lui-même en remplissant un formulaire HTML, l'application reçoit des données de l'utilisateur dans des requêtes standards, qui, pour des raisons de simplicité, seront censées être envoyées dans une requête GET.

Par exemple, les valeurs suivantes: 

Username: tony
Password: Un6R34kb!e
E-mail: s4tan@hell.com

produira la demande: 

http://www.example.com/addUser.php?username=tony&password=Un6R34kb!e&email=s4tan@hell.com

L'application construit le nœud suivant: 

<user> 
       <username>tony</username> 
       <password>Un6R34kb!e</password> 
       <userid>500</userid>
       <mail>s4tan@hell.com</mail>
</user>

qui sera ajoutée à la XMLDB: 

<?xml version="1.0" encoding="ISO-8859-1"?> 
<users> 
       <user> 
               <username>gandalf</username> 
               <password>!c3</password> 
               <userid>0</userid>
               <mail>gandalf@middleearth.com</mail>
       </user> 
       <user> 
               <username>Stefan0</username> 
               <password>w1s3c</password> 
               <userid>500</userid>
               <mail>Stefan0@whysec.hmm</mail>
       </user> 
       <user> 
               <username>tony</username> 
               <password>Un6R34kb!e</password> 
               <userid>500</userid>
               <mail>s4tan@hell.com</mail>
       </user> 
</users>

Découverte

La première étape dans le but de tester une application pour la présence d'une vulnérabilité d'injection XML consiste à essayer d'insérer des métacaractères XML.

Les métacaractères XML sont les suivants:

A titre d'exemple, supposons que il y a l'attribut suivant: 

<nowiki><node attrib='$inputValue'/></nowiki>

Donc, si: 

inputValue = foo'

est instancié, puis est inséré en tant que valeur attrib: 

<nowiki><node attrib='foo''/></nowiki>

alors, le document XML résultant ne sera pas bien formé. 

<node attrib="$inputValue"/>

Donc, si: 

$inputValue = foo"

Est substitué: 

<node attrib="foo""/>

le document XML résultant sera invalide. 

Username = foo<

l'application va construire un nouveau nœud: 

<user> 
    <username>foo<</username> 
    <password>Un6R34kb!e</password> 
    <userid>500</userid>
    <mail>s4tan@hell.com</mail>
</user>

mais, à cause de la présence de l'ouverture ”<“, le document XML est valide.