Sécurisez vos applications web avec l'OWASP

Pour comprendre ce que sont les XXE, il faut d’abord définir le langage XML. Le langage XML (Extensible Markup Language) a été créé pour stocker, partager et transporter des données entre systèmes. Il est indépendant de la plateforme et du langage. 

XML est utilisé pour transmettre des données d'une plateforme à l'autre. Beaucoup d'applications web utilisent XML pour gérer les données. Il ressemble à HTML, mais fonctionne différemment car HTML est utilisé pour présenter les données en hypertexte sur un navigateur.

En XML, il existe des entités internes et externes :

• Une entité interne est essentiellement une référence XML à un objet interne. 

• Une entité externe est une référence XML à une source externe comme un chemin de fichier ou une URL, des images, des références de documents ou des liens de fichiers. Lorsque cette balise d'entité externe est intégrée à une page web, elle sera directement affichée depuis son emplacement externe.

Une attaque XXE ou injection XXE est un type d'attaque contre une application qui utilise XML. Cette attaque se produit lorsque l'entrée XML contenant une référence à une entité externe est traitée par un analyseur XML mal configuré. Cette attaque peut entraîner la divulgation de données confidentielles, un déni de service, une falsification de requête côté serveur et d'autres impacts sur le système.

Un attaquant peut avoir délibérément choisi de placer un chemin d'accès dans le XML pour obtenir un accès non autorisé au contenu d’un fichier. Cette attaque est une forme d’injection.

Une injection XXE est utilisée pour lire le contenu d'un fichier et l'afficher sur le navigateur. 

Imaginons qu’une personne malveillante détecte une faille présente dans le système de gestion des utilisateurs d’un serveur Linux.

À partir de cette faille, il souhaite afficher le contenu des informations de connexion des utilisateurs, présent dans le fichier /etc/passwd. Disons que l’attaquant pourrait essayer une injection XXE via un code qui utilise un fichier XML suivant :

<!DOCTYPE foo [

<!ELEMENT foo ANY >

<!ENTITY inject SYSTEM "file:///etc/passwd" >]>

<User>

<Name>Grominet</name>

<Prompt>/bin/bash</Prompt>

<Group>&inject;</Group>

</User>

Quand la requête va être envoyée au serveur, le programme va chercher l’utilisateur Grominet, renvoyer le prompt utilisé, ici/bin/bash, mais au lieu de renvoyer le groupe, il va renvoyer le contenu de&inject, c'est-à-dire le contenu du fichier/etc/paswd.

Respectez les bonnes pratiques de développement

• Appliquez la validation des données d'entrée : pour empêcher les attaques communes, il est possible de blacklister certains caractères comme les balises script.

• Appliquez la transformation des entrées : vous pouvez encoder toutes vos entrées dans une entité de caractères HTML ou du texte pour qu'il n'exécute aucun script. Il existe des fonctions simples et des bibliothèques qui peuvent vous aider à encoder tout votre HTML et JavaScript.

• Configurez vos cookies avec le flag HttpOnly.

• Des entités XML externes peuvent être utilisées pour révéler des données sensibles, des images et des références de documents enregistrées sur un ordinateur.

• Les entités XML externes devraient être désactivées.

Un pirate peut créer un lien XSS et le distribuer par le biais de l'ingénierie sociale pour accéder au navigateur d'un utilisateur.

Si l'utilisateur clique sur le lien alors qu'une session est encore ouverte sur sa banque, le pirate peut détourner un jeton de session dans le navigateur (en temps réel) pour accéder à cette session.

Ces requêtes peuvent également rester inactives jusqu'à ce que l'utilisateur ait créé une session sur son navigateur. Ce type de lien XSS peut être un formulaire de demande GET, mais il pourrait aussi bien s'agir d'un formulaire de demande POST. Par exemple, un lien qui effectue une transaction bancaire.

Cette transaction bancaire se produirait à l'insu de l'utilisateur qui pourrait ou non réaliser que le navigateur a toujours la session bancaire ouverte.

Dans la famille du contrôle de sécurité, il y a deux membres à ne pas négliger pour éviter ce genre de problème : le durcissement et la gestion des mises à jour. Ces deux éléments de sécurité concernent moins les développeurs (mais pas totalement) que les administrateurs système, ou la DSI en général.

Le durcissement, ou hardening en anglais, consiste à fortifier une machine, que ce soit un poste client ou un serveur. L’objectif premier est la réduction du nombre de composants, que ce soit des utilisateurs, des applications ou autres, qui sont présents sur un système. L’application de l’adage “Less is More” est un bon début. 

La gestion des mises à jour et des correctifs a aussi un rôle important dans la sécurité d’un système d’information. Il s’agit d’un processus mis en place pour pouvoir gérer les différentes mises à jour d’applications ou de composants pour réduire les risques de failles de sécurité. Ce processus repose sur de bonnes pratiques de gestion de parc, comme la mise en place d’un inventaire du matériel, la veille technologique autour des failles et vulnérabilités. Une logique de gestion des risques doit être mise en place, avec les rédactions de procédures en cas de détection.

• Des entités XML externes peuvent être utilisées pour révéler des données sensibles, des images et des références de documents enregistrées sur un ordinateur.

• Les entités XML externes devraient être désactivées.

• Les attaques CSRF peuvent se produire via social engineering et effectuent des transactions à l'insu de l'utilisateur.

• Validez toujours les entrées utilisateurs.

• Le durcissement et la gestion des mises à jour vous protégeront contre ce type de vulnérabilités.

Dans le prochain chapitre, nous verrons comment se prémunir des piratages de session.