Applications, sites et API

Particuliers et entreprises

Exploitation des entités externes XML

XML external entity injection / XXE

Un document XML fait lire au service un fichier ou une ressource qu’il n’aurait pas dû consulter.

Révision éditoriale : Comprendre : 2 min · Cas technique et détails : 4 min
Je pense être concerné : que faire ?
Illustration pédagogique : exploitation des entités externes xml.

Comprendre et agir

Découvrez le piège à partir d’un exemple, puis les gestes que vous pouvez faire. Vous pouvez suivre cette lecture sans connaissances en informatique.

Une situation concrète

Une association importe un catalogue XML envoyé par un partenaire. Le lecteur suit une référence présente dans le document et ouvre un fichier local de configuration. Le résultat de l’import révèle alors une partie de ce fichier.

Comment cela fonctionne

XML permet de décrire des données structurées. Certains lecteurs peuvent aussi résoudre des entités externes : des références vers un fichier ou une autre ressource. Une attaque XXE utilise cette fonction pour faire lire au service quelque chose que l’expéditeur ne devrait pas obtenir. Selon le lecteur et sa configuration, elle peut révéler des fichiers, déclencher des connexions internes ou perturber le service.

Comment le piège fonctionne
  1. Un document est importé

    Il contient une référence à une ressource externe.

  2. Le lecteur suit cette référence

    Il utilise les accès du serveur.

  3. Une ressource est exposée

    Selon le chemin de retour et les droits du service.

Ce que vous pouvez faire

Vos premiers réflexes

Signalez un import qui affiche des données étrangères au document envoyé. Transmettez le fichier au support par son canal prévu, sans multiplier les essais sur le service.

Si vous êtes responsable du service ou de l’organisation

Identifiez les lecteurs XML réellement utilisés. Désactivez la résolution des ressources externes inutiles et vérifiez les accès aux fichiers comme les sorties réseau du service.

Un point à vérifierUne idée reçue à corriger

Bloquer les sorties Internet ne suffit pas si le lecteur XML peut encore ouvrir des fichiers locaux sensibles.

À vous de décider

Le service d’import ne peut pas accéder à Internet. Un document XML peut-il encore lui faire lire un fichier local ?

Prenez un moment pour répondre et expliquer votre choix, puis ouvrez la correction.

Voir la réponse expliquée

Oui, si son lecteur autorise ce type de référence et si le compte du service peut ouvrir le fichier. Il faut régler le parseur et limiter ses permissions ; bloquer Internet ne couvre pas cette lecture locale.

Analyser un cas technique

Ce cas s’adresse aux personnes qui développent, administrent ou analysent ces systèmes. Si vous découvrez le sujet, commencez par « Comprendre et agir ».

Étude de cas fictive

Un import XML lit une ressource locale inattendue

Le document de test conduit le parseur à ouvrir fixture-private.txt, puis un marqueur de ce fichier apparaît dans le résultat de l’import. Le scénario établit donc une lecture locale et un chemin de retour. Il ne nécessite aucune connexion réseau, ce qui explique pourquoi un filtrage Internet ne l’aurait pas arrêté.

Les champs présentés sont ajoutés pour l’exercice. Sur un service réel, il faut retrouver les options du parseur, les éventuelles transformations et la sortie livrée. Une erreur mentionnant un fichier ou un événement DNS aurait une portée plus limitée que le retour du marqueur.

Le traitement corrigé refuse la déclaration de type de document, car le format métier n’en a pas besoin. Si un service en a un besoin réel, il doit limiter précisément la résolution à des ressources de confiance. Le module Magento CVE-2024-34102 de Metasploit documente un autre cas de lecture par XXE ; notre import reste une reconstitution pédagogique indépendante.

Le déroulement en schéma

Qui échange avec quiLisez les échanges de haut en bas. Le point marque le départ et la flèche l’arrivée. Les vérifications après correction ne sont pas la suite de l’attaque.

Faites défiler le diagramme pour suivre les échanges ; les noms des acteurs restent en haut. Sur petit écran, faites aussi défiler de gauche à droite.

Étape
ExpéditeurDocument XML
ImporteurService applicatif
ParseurRésolution d’entités
Ressource localeFichier factice
  1. Action

    Dépôt du document

    Expéditeur vers Importeur

    Trace job xml-21

  2. Action

    Analyse du XML

    Importeur vers Parseur

    Trace résolution activée

  3. Action

    Ouverture de la référence externe

    Parseur vers Ressource locale

    Trace fichier local

  4. Réponse

    Lecture du marqueur

    Ressource locale vers Parseur

    Trace donnée factice

  5. Réponse

    Résultat contenant le marqueur

    Parseur vers Importeur

    Trace lecture et retour reliés

  6. Réponse

    Résultat d’import livré

    Importeur vers Expéditeur

    Trace exposition de test

  7. Refus / blocage

    Import après correction

    Importeur vers Parseur

    Trace DOCTYPE refusé

Comment repérer cette attaque

Indices à rechercher

  • Un import provoque une connexion réseau inattendue depuis le serveur.
  • Une erreur de lecture mentionne une entité externe ou une ressource locale.
  • Le résultat contient des fragments étrangers aux données envoyées.

Examiner les échecs de résolution, les accès inhabituels du processus de lecture et les destinations secondaires au moment des imports. Comparer les fichiers réellement ouverts et les résultats livrés, lorsque les preuves existent, sans conserver systématiquement les documents privés dans les journaux.

Quelles informations comparer

Relier le document préservé, le job d’import, la résolution et la sortie effective. Dans l’exercice, le retour du marqueur rattache la lecture au résultat ; en production, ce lien peut manquer faute de collecte.

Ce que ces indices ne permettent pas de conclure

Une ouverture de fichier ne prouve pas que son contenu a quitté le serveur. L’absence de connexion réseau n’écarte pas la lecture locale. Les options d’un parseur peuvent changer d’une version à l’autre.

Comment réagir

Suspendre le traitement exposé et durcir le parseur sur tous les chemins concernés. Préserver les documents pour l’analyse isolée. Évaluer les ressources accessibles avec l’identité du service, les sorties possibles et les secrets à remplacer après correction.

Vérifier la correction

L’équipe responsable du système peut utiliser ces contrôles dans un environnement de test autorisé. Vous pouvez lire et comprendre le cas sans effectuer ces manipulations.

  1. Le lecteur refuse les DTD inutiles et n’ouvre aucune ressource factice locale ou distante interdite.
  2. Les conversions intermédiaires et autres lecteurs XML appliquent les restrictions attendues.
  3. Les documents métier valides restent importables et le service conserve des permissions minimales.

À vous de raisonner

Le test retourne le marqueur d’un fichier local factice sans aucune connexion réseau. Un filtrage des destinations Internet aurait-il corrigé ce cas ?

Quelle décision prendriez-vous, et sur quel indice vous appuieriez-vous ? Répondez avant d’ouvrir la correction.

Comparer avec le raisonnement expliqué

Non. La ressource a été ouverte localement avec les permissions du service. Il faut empêcher cette résolution dans le parseur et limiter les accès aux fichiers. Pour ce format qui n’utilise pas de DTD, son refus est vérifiable ; les imports valides doivent aussi être testés.

Consulter les détails techniques

Les extraits permettent de s’exercer à lire les traces du cas. Si vous disposez des outils et des accès nécessaires, le guide de collecte vous aide aussi à rechercher ces informations.

Lire les extraits commentés (reconstitution fictive)

Ces extraits contiennent des valeurs fictives. Certains champs correspondent à ceux des outils documentés ; d’autres réunissent plusieurs sources pour faciliter l’explication. Vos propres exports pourront donc avoir une autre forme. Lisez d’abord les explications des champs, puis repérez-les dans les extraits.

external_entity_resolution
État inventé pour rendre la configuration visible dans l’exercice ; vérifier les options réelles du lecteur déployé.
result_marker_returned
Observation du marqueur factice dans le résultat de laboratoire, et non preuve d’un vol de configuration en production.

Reconstitution d’un import dans un environnement de test

JSONL

Traces fictives d’un lecteur instrumenté ; resource désigne un fichier factice du laboratoire. Aucun parseur XML ne garantit ce format de journal.

{"job":"xml-21","environment":"isolated_test","external_entity_resolution":"enabled","resource":"fixture-private.txt","local_read":true}
{"job":"xml-21","result_marker_returned":true,"network_connection":false}
{"job":"xml-22","environment":"isolated_test","doctype":"rejected","local_read":false,"result_marker_returned":false}
Préparer une collecte dans votre environnement

Utilisez les sources disponibles dans vos outils et auxquelles vous êtes autorisé à accéder. Vous pouvez comprendre la fiche sans posséder ces outils. Vérifiez que les journaux étaient activés pendant la période étudiée. Gardez l’export original avec son fuseau horaire et sa provenance dans un espace à accès restreint. Pour l’analyse, travaillez sur une copie dont vous avez retiré les secrets.

  1. Service concerné — audit et historique à vérifier

    Où les trouver
    Dans l’outil d’administration ou les journaux du service concerné. Demander à son mainteneur où sont enregistrées les décisions d’autorisation et les opérations métier.
    Quoi relever
    Retrouver le job, le parseur, ses options et les transformations du document. Conserver les erreurs de résolution et le résultat livré, avec des accès restreints s’ils contiennent des données privées.
    Accès et prérequis
    Il n’existe ni fichier ni vocabulaire universels. Les champs proposés ici doivent être instrumentés s’ils manquent ; ne pas enregistrer mots de passe, jetons ou contenu privé intégral.
    Documentation : Service concerné — audit et historique à vérifier

  2. Linux — auditd

    Où les trouver
    Sur le serveur concerné, dans le fichier log_file d’auditd, généralement /var/log/audit/audit.log. Les enregistrements SYSCALL, EXECVE et PATH d’un même événement partagent le numéro dans msg=audit(...).
    Quoi relever
    Si des règles d’audit couvraient la ressource, relier l’ouverture au processus du parseur et à son résultat. Une simple mention de chemin dans une erreur ne prouve pas une lecture réussie.
    Accès et prérequis
    Service actif et règles d’audit adaptées avant les faits. Linux n’enregistre pas automatiquement toutes les exécutions et lectures ; les arguments et chemins collectés peuvent être sensibles.
    Documentation : Linux — auditd

Si vous pensez être concerné

Si vous utilisez le service

Signalez un import qui affiche des données étrangères au document envoyé. Transmettez le fichier au support par son canal prévu, sans multiplier les essais sur le service.

Pour l’équipe qui exploite le service

  1. Conservez le document et les identifiants de l’import dans un espace d’analyse protégé.
  2. Faites désactiver la résolution dangereuse et vérifier les autres traitements XML.
  3. Évaluez les fichiers lus, les connexions émises et les secrets éventuellement exposés.

Pour comprendre votre situation et trouver de l’aide : obtenir une assistance sur 17Cyber. Dans une organisation, prévenez aussi le responsable ou prestataire chargé de la sécurité.

Sources et repères pour approfondir

Sur des sujets proches

Falsification de requête côté serveur ↗Traversée de répertoires ↗Vol, exfiltration et violation de données ↗Toutes les fiches ECRAN →