XML : Extensible Markup Language

To the non-french speaker, note that you can translate the articles using the Google Trad widget situated at the bottom of all pages.

Avant de commencer à parler du XML je pense qu’il est utile de connaître l’histoire de ce langage. Pour cela il est nécessaire de retourner plus de 50 ans en arrière. A partir de 1969,  Charles Goldfarb à l’aide de ses collègues créent le premier langage de balisage au monde : le GML (du nom de leurs créateurs Goldfarb, Mosher et Lorie).

Ce premier langage de balisage avait pour but de faciliter l’accès aux données pour les juristes (Charles Goldfarb était juriste de formation). A partir du GML a été crée un deuxième langage de balisage : le SGML (Standard Generalized Markup Language) et à partir du SGML est apparu le XML (ainsi que la plupart des autres langages de balisage que l’on utilise maintenant : HTML, XSLT ect… ).

Quand j’ai commencé à manipuler les langages de balisage j’avais du mal à comprendre la différence entre le HTML et le XML et puis j’ai trouvé cet article qui l’explique très bien (en anglais). Du coup pour les non anglophones voici un petit résumé de ce que sont ces différents langages.

Le HTML (HyperText Markup Language) est un langage de balisage qui permet de structurer une page web. Avec le HTML on peut compartimenter une page web, intégrer des images, des vidéos ect… C’est donc un langage de « mise en page ».

Le XML (Extensible Markup Language) permet quant à lui d’échanger des données de façon formater, compréhensible à la fois pour l’homme et la machine.

Maintenant qu’on sait faire la différence entre le HTML et le XML on va pouvoir commencer à travailler 😁 ! Le but premier de cette série d’articles est de présenter la faille XXE qui utilise justement le XML mais avant de passer à l’exploitation on va voir comment fonctionnelle XML, comment créer des fichiers XML valides etc…

I/ Introduction au XML

Comme nous l’avons vu plus haut, le XML est un langage de balisage donc notre fichier XML sera composé de balises :

 <balise></balise>

On peut nommer nos balises comme bon nous semble. La seule contrainte qui existe c’est celle de la compréhension. Il vaut mieux bien nommer nos balises histoire de ne pas se perdre dans notre fichier. Entre ces balises on peut ajouter du contenu (du texte, des nombres …) :

<constructeur>Asus</constructeur>

Afin de définir (préciser) le contenu d’une balise on utilise des attributs. Par exemple si dans notre fichier XML on stocke les différents constructeurs de PC au monde alors on aura plusieurs balises qui contiendront le nom des constructeurs et qui auront pour attribut le pays d’origine de ces constructeurs :

xml.png

Bien évidemment rien ne nous empêche d’empiler les balises les unes sur les autres. Par exemple on pourrait stocker dans notre fichier XML le nom du constructeur, la date de création de l’entreprise, son statut social etc… :

constructeurdetail.png

Comme tout document, notre fichier a besoin d’un prologue. Ce prologue va renseigner plusieurs informations :
-La version d’XML utilisée
-Le format d’encodage des données

Voici notre fichier XML complet :

constructeur.png

Pour qu’un fichier XML soit utilisable il doit répondre à plusieurs critères définis :

  • Les fichiers XML doivent avoir une balise racine
  • Les balises XML doivent être correctement fermées
  • Les balises XML doivent être correctement nommées
  • Les balises XML doivent être correctement superposées
  • Les attributs XML doivent être contenus entre quotes.

Si votre fichier respecte ces règles alors on dira de lui qu’il est « well-formed ». Si vous avez un doute quant à la validité de votre document je vous invite à vous servir des validateurs disponibles en ligne (comme celui de la W3S).

Si on reprend le précédent fichier on remarque que le prologue est correctement renseigné, qu’il y a bien une balise racine (<constructeur>), qu’il n’y a pas d’erreurs d’imbrication mais que par contre il y a une balise qui n’est pas correctement fermée :

 <statut>jesepa</status>

Du coup si on passe notre fichier au validateur nous aurons une erreur. Si on la corrige et qu’on repasse le fichier au validateur on sera bon :

noerrors

Notre fichier est bien well-formed ! Avec ça vous connaissez la base du XML. Vous allez voir qu’on peut cependant aller plus loin, par exemple on peut définir une structure à notre fichier XML en se servant des DTD.

II/ Structuration des fichiers XML

Les DTD (Document Type Definition) sont un ensemble de règles qui permettent de créer une structure à notre document XML. Avec les DTD on va pouvoir imposer à une balise d’en contenir une autre ou de contenir une valeur, on va pouvoir imposer l’utilisation d’un attribut dans une balise etc…

Il existe deux types de DTD, les DTD internes et les DTD externes. Dans le premier cas on va écrire le DTD directement dans le fichier XML tandis que dans le deuxième cas on l’écrira à part dans un fichier .dtd. Dans notre cas nous utiliserons un DTD interne. Et pour illustrer le tout nous reprendrons notre fichier avec le constructeur :

noerrors

  • DTD sur les balises :

Pour définir une règle portant sur les balises on utilisera cette syntaxe :

<!ELEMENT balise (contenu)>

A la place de « contenu » on peut avoir deux valeurs :
-Une balise
-Une valeur

Par exemple la balise <constructeur> doit contenir la balise <nom>, <creation> et <statut>. Au niveau du DTD on peut déclarer ceci :

<!ELEMENT constructeur (nom, creation, statut)>

A l’inverse les balises <nom>, <creation> et <statut> ne contiennent pas d’autres balises mais des valeurs. Voici comment on on pourrait le déclarer :

<!ELEMENT nom (#PCDATA)>
<!ELEMENT creation (#PCDATA)>
<!ELEMENT statut (#PCDATA)>

Ici nous venons de stipuler que les balises nom, création et statut devront obligatoire apparaître dans notre fichier XML dans cet ordre là et avoir du contenu autre qu’une balise !

Notez qu’il est aussi possible de spécifier qu’une balise ne contiendra rien via le mot clé EMPTY :

<!ELEMENT balise EMPTY>

Ou contenir n’importe quoi (une balise ou une valeur) via le mot clé ANY :

<!ELEMENT balise ANY>

Bien évidemment il existe d’autres opérateurs qui permettent de répondre à différentes architectures. Par exemple on peut stipuler qu’une balise contiendra soit la balise <balise1>, soit la balise <balise2> en utilisant cette syntaxe :

<!ELEMENT balise (balise1 | balise2)>

Dans le même ordre on peut indiquer qu’une balise peut contenir plusieurs fois (entre 0 et une infinité de fois) la balise 2 via le mot clé * :

<!ELEMENT balise (balise1, balise2*)>

Ou encore que la balise2 peut apparaître au minimum une fois et au maximum une infinité de fois avec le mot clé + :

<!ELEMENT balise (balise1, balise2+)>

Ou ne pas forcément apparaître via le mot clé ? :

<!ELEMENT balise (balise1, balise2?)>

Prenons un exemple concret, nous avons un constructeur (Asus) qui produit plusieurs ordinateurs. Chacun de ces ordinateurs a au minimum un écran, une carte mère, de la mémoire et un disque dur.

Voici à quoi ressemblerait nos règles DTD :

<!ELEMENT constructeur (ordinateur+)>
<!ELEMENT ordinateur (nom, ecran, carte, memoire, stockage)>
<!ELEMENT nom (#PCDATA)>
<!ELEMENT ecran (#PCDATA)>
<!ELEMENT carte (#PCDATA)>
<!ELEMENT memoire (#PCDATA)>
<!ELEMENT stockage (#PCDATA)>

Pour les intégrer à notre fichier XML il faudra juste ajouter une autre balise :

<!DOCTYPE racine [ ]>

En remplaçant le mot « racine » par le nom de la balise racine et en mettant les règles entre les « [] » soit :

<!DOCTYPE constructeur [
<!ELEMENT constructeur (ordinateur+)>
<!ELEMENT ordinateur (nom, ecran, carte, memoire, stockage)>
<!ELEMENT nom (#PCDATA)>
<!ELEMENT ecran (#PCDATA)>
<!ELEMENT carte (#PCDATA)>
<!ELEMENT memoire (#PCDATA)>
<!ELEMENT stockage (#PCDATA)> 
] >

Voici le fichier final :

fichierfinal.png

  • DTD sur les attributs :

Ce que nous avons fait sur les balises, nous pouvons le faire sur les balises en appliquant une syntaxe quasi similaire :

<!ATTLIST balise attribut type mode>

On retrouve le mot clé ATTLIST qui implique que l’on applique la règle aux attributs, le mot « balise » qui sera le nom de la balise affectée, le mot « attribut » qui sera… l’attribut et les mots « types » et « mode ». A la place du mot type on spécifiera les différentes valeurs disponibles pour l’attribut.

Voyez la règle suivante :

<!ATTLIST stockage valeur (8 | 16) mode>

Cette déclaration implique que l’attribut valeur de la balise stockage aura pour valeur soit 8 soit 16.


Il existe d’autres règles qui s’appliquent aux attributs mais pour ma part je ne les trouve pas très utile donc je ne les détaillerai pas plus que ça. Voilà pour cette introduction au XML. Si j’ai écrit cette article c’est parce qu’il y a une jolie faille qui permet de faire pas mal de choses : la faille XXE que je vous présente ici !

 

Un commentaire

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion /  Changer )

Photo Google

Vous commentez à l'aide de votre compte Google. Déconnexion /  Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion /  Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion /  Changer )

Connexion à %s