Sécurité applicative : Attaque de Déni de Service via DTD/XML (toutes plateformes)
Sécurité applicative : Attaque de Déni de Service via DTD/XML par Bryan Sullivan
Récemment des failles de sécurité ont été détectées sur les parseurs XML .
Ces failles , notamment des problèmes de fuites de mémoires, ont déjà été utilisées pour réaliser des attaques de denis de service applicatives .
Bryan Sullivan,auteur de “AJAXSecurity” (Addison-Wesley, 2007), livre dans son article quelques exemples de ce type d'attaque et les moyens de s'en protéger.
Les techniques d'attaques expliquées dans le résumé ci-dessous exploitent la technologie de validation de XML des DTD.
Pour en être victime il n'est pas nécessaire d'utiliser cette forme de validation, ne pas l'interdire expressément est suffisant.
Pour toutes les personnes concernées, notamment les utilisateurs .NET, nous recommandons fortement la lecture de son article : XML Denial of Service Attacks and Defenses
Les points faibles de la validation via DTD
Les DTD sont une technologie antérieures au XML prévues pour valider des document comme le SGML et HTML .De fait, elle n'est pas présente sous un format XML et son traitement s'écarte quelque peu de celui d'autre technologies plus récentes.
Deux points particuliers posent ici problème :
1)Pour la validation , contrairement aux XML Schema, on n'est pas obligé de faire référence au schéma validant, il peut être directement inclus dans le XML .Le comportement par défaut d'un parseur validant sera toujours de vérifier cette DTD interne avant tout traitement .
2)Les entités externes : les DTD permettent de déclarer le remplacement d'entités «*personnelles*» par une chaîne de caractères.
Exemple :
Code:
1
2
3
4
5
6
7
8
9
10
11
| <?xml version="1.0"?>
<!DOCTYPE employees [
<!ELEMENT employees (employee)*>
<!ELEMENT employee (#PCDATA)>
<!ENTITY companyname "Contoso Inc.">
<!ENTITY divisionname "&companyname; Web Products Division">
]>
<employees>
<employee>Glenn P, &divisionname;</employee>
<employee>Dave L, &divisionname;</employee>
</employees> |
Ce sont les deux points sur lesquels s'appuient les récentes attaques applicatives via XML
L'attaque dit XML BOMB
Mécanisme
Exemple:
Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
| <?xml version="1.0"?>
<!DOCTYPE lolz [
<!ENTITY lol "lol">
<!ENTITY lol2 "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;">
<!ENTITY lol3 "&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;">
<!ENTITY lol4 "&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;">
<!ENTITY lol5 "&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;">
<!ENTITY lol6 "&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;">
<!ENTITY lol7 "&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;">
<!ENTITY lol8 "&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;">
<!ENTITY lol9 "&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;">
]>
<lolz>&lol9;</lolz> |
Ce XML est bien formés et valides, selon les règles de la DTD.
Lors du chargement XML de ce document par le parseur, il voit un élément racine, "lolz", contenant le texte "&lol9;". Toutefois, «&lol9;" est une entité définie décrite par une chaîne contenant dix "&lol8;" Chaque "&lol8;" string est une entité définie qui s'étend à dix &lol7;* et ainsi de suite. Après traitement, ce petit (<1 Ko) bloc de XML contiendra 100 millions de "lol" , soit près de 300 Mo de mémoire!
Mesure de défense
La meilleure défense contre tous les types d'attaques entité XML est de tout simplement désactiver complètement l'utilisation des schémas en ligne DTD dans vos parseurs d'analyse syntaxique XML. Il s'agit d'une simple application du principe de la réduction de la surface d'attaque: si vous n'utilisez pas une fonctionnalité, désactivez-la de telle sorte que les attaquants ne soient pas en mesure d'en abuser.
Si vous voulez vraiment utiliser les DTD, vous devez prendre des mesures supplémentaires pour protéger votre code. La première étape consiste à limiter la taille des entités .En effet, Les attaques décrites agissent en créant des entités s'élargissant en chaînes énormes et forçant l'analyseur à consommer de grandes quantités de mémoire. Il vous faudra trouver le paramétrage de votre parseur le permettant .
L'attaque via Entité Externes
Mécanisme
On peut définir les entités via des liens externes, exemple :
Code:
<!ENTITY stockprice SYSTEM "http://www.contoso.com/currentstockprice.ashx">
Le plus simple pour abuser de la fonctionnalité de l'entité externe est d'envoyer le parseur XML à une ressource qui lui enverra un réponse trop volumineuse voir infinie via un script .
Mesure de défense
Comme précédemment, si vous n'utilisez pas cette capacité le plus simple pour vous en prémunir est de l'interdire.
Dans le cas contraire, diverse opérations sont nécessaires.
Vous devrez changer le comportement validant de trois façons. Premièrement, vous devrez fixer un délai de demande afin de prévenir les attaques par retard infini, ensuite , limiter la quantité de données qu'elle permettra de récupérer.
Si possible, restreignez cette utilisation à des URI locales.
En conclusion
Même si vos utilisez une autre technologie comme XML Schema pour valider vos XML, une DTD incluse sera traitée par défaut en priorité .
Si vos applications utilisent du XML, et en particulier en reçoivent de l'extérieur, mais n'utilisent pas de DTD, désactivez son utilisation ou au minimum celle des DTD incluses, autrement paramétrez son usage .
Source
:fleche: XML Denial of Service Attacks and Defenses
Lire aussi
:fleche: La rubrique XML/XSL et SOAP (actu, forum, tutos) de Développez
:fleche: Des failles critiques en série dans les bibliothèques XML, problème résolu ?
Et vous ?
:fleche: Que pensez-vous de ces failles ? Sachant que les DTD sont une technologies plus anciennes que le XML, prévu pour parser des document comme HTML ou SGML, sont-elles maintenant dangeureusement obsolètes ?
