Affichage des résultats du sondage: Les DTD sont elles devenues une technologie inadaptée par leurs failles ?

Votants
15. Vous ne pouvez pas participer à ce sondage.
  • Oui

    7 46,67%
  • Non

    4 26,67%
  • autres avis

    4 26,67%
+ Répondre à la discussion Actualité déjà publiée
Affichage des résultats 1 à 3 sur 3
  1. #1
    Responsable Développement Web


    Avatar de Bovino
    Homme Profil pro Didier Mouronval
    Développeur Web
    Inscrit en
    juin 2008
    Messages
    22 420
    Détails du profil
    Informations personnelles :
    Nom : Homme Didier Mouronval
    Âge : 44
    Localisation : France, Gironde (Aquitaine)

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : juin 2008
    Messages : 22 420
    Points : 87 218
    Points
    87 218
    Billets dans le blog
    4

    Par défaut 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
    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 ?
    Pas de question technique par MP !
    Tout le monde peut participer à developpez.com, vous avez une idée, contactez-moi !
    Mes formations video2brain : La formation complète sur JavaScriptJavaScript et le DOM par la pratiquePHP 5 et MySQL : les fondamentaux
    Mon livre sur jQuery
    Module Firefox / Chrome d'intégration de JSFiddle et CodePen sur le forum

  2. #2
    Membre habitué
    Profil pro
    Étudiant
    Inscrit en
    janvier 2007
    Messages
    126
    Détails du profil
    Informations personnelles :
    Âge : 32
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Étudiant
    Secteur : High Tech - Électronique et micro-électronique

    Informations forums :
    Inscription : janvier 2007
    Messages : 126
    Points : 117
    Points
    117

    Par défaut

    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é....

  3. #3
    Modérateur

    Inscrit en
    septembre 2004
    Messages
    9 879
    Détails du profil
    Informations forums :
    Inscription : septembre 2004
    Messages : 9 879
    Points : 16 369
    Points
    16 369

    Par défaut

    À 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.

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •