IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Sécurité applicative : Attaque de Déni de Service via DTD/XML

Le , par Community Management

23PARTAGES

1  0 
Les DTD sont elles devenues une technologie inadaptée par leurs failles ?
Oui
50 %
Non
25 %
autres avis
25 %
Voter 16 votants
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 : Sélectionner tout
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 : Sélectionner tout
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 : Sélectionner tout
<!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
XML Denial of Service Attacks and Defenses

Lire aussi

La rubrique XML/XSL et SOAP (actu, forum, tutos) de Développez
Des failles critiques en série dans les bibliothèques XML, problème résolu ?

Et vous ?

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 ?

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de mrjay42
Membre habitué https://www.developpez.com
Le 13/11/2009 à 8:39
Bel article, interessant et tout.
Avec un joli code à tester de bon matin dans un petit parseur XML "pour voir"

J'apprécie particulièrement cet article parce qu'il me fournit un argument de plus envers la non utilisation des DTD : syntaxe non xml, difficulté à lire et à interpréter et maintenant faille de sécurité....
1  0 
Avatar de thelvin
Modérateur https://www.developpez.com
Le 13/11/2009 à 14:53
À mon avis les DTD sont devenues une technologie inadaptée, non pas par leurs failles de sécurité, mais depuis la large adoption des XML namespaces.

Concernant toutes ces attaques, je pense surtout que ce n'est pas assez connu. Beaucoup de gens adoptent XML par effet de buzz sans avoir le bagage technique pour comprendre ce qu'il y a derrière, et les bibliothèques genre Xerces ne protègent pas par défaut de ce genre d'attaque par déni de service.
Pourtant, elles pourraient, je trouve que c'est dommage. L'un des buts de XML est de se simplifier la vie, et XML en soi en est parfaitement capable. Si la toolchain suit.
1  0