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

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

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

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

    8 50,00%
  • Non

    4 25,00%
  • autres avis

    4 25,00%
Valider XML Discussion :

Sécurité applicative : Attaque de Déni de Service via DTD/XML (toutes plateformes)


Sujet :

Valider XML

  1. #1
    Community Manager

    Profil pro
    Inscrit en
    Avril 2014
    Messages
    4 207
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Avril 2014
    Messages : 4 207
    Points : 13 061
    Points
    13 061
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    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 - Visualiser dans une fenêtre à part
    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 - Visualiser dans une fenêtre à part
    <!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 ?
    Pour contacter les différents services du club (publications, partenariats, publicité, ...) : Contacts

  2. #2
    Membre habitué
    Profil pro
    Étudiant
    Inscrit en
    Janvier 2007
    Messages
    126
    Détails du profil
    Informations personnelles :
    Âge : 41
    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 : 177
    Points
    177
    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

    Profil pro
    Inscrit en
    Septembre 2004
    Messages
    12 551
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Septembre 2004
    Messages : 12 551
    Points : 21 607
    Points
    21 607
    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.
    N'oubliez pas de consulter les FAQ Java et les cours et tutoriels Java

Discussions similaires

  1. Détecter une attaque par déni de service
    Par BenjaminN dans le forum Apache
    Réponses: 1
    Dernier message: 07/07/2011, 12h14
  2. Réponses: 2
    Dernier message: 08/03/2011, 12h36
  3. Réponses: 0
    Dernier message: 07/03/2011, 17h36
  4. Les attaques par déni-de-service deviennent plus sophistiquées
    Par Katleen Erna dans le forum Actualités
    Réponses: 7
    Dernier message: 22/01/2011, 15h09
  5. Réponses: 2
    Dernier message: 13/11/2009, 14h53

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo