Path Traversal est une vulnérabilité présente depuis des décennies dans les manuels de sécurité, mais qui continue d’apparaître dans les applications modernes. L’Institut National de Cybersécurité (INCIBE) a consacré une nouvelle étude à cette faille, classée comme CWE-22, et avertit que le problème ne doit plus être uniquement associé aux applications web traditionnelles : microservices, conteneurs, API, plateformes cloud et systèmes d’intelligence artificielle peuvent également être exposés lorsque qu’ils utilisent des chemins contrôlables depuis l’extérieur.
Les clés du Path Traversal en 30 secondes
- Le Path Traversal permet de tenter de sortir du répertoire autorisé en manipulant les chemins traités par une application.
- Le risque concerne des configurations, identifiants, clés API, journaux (logs) et autres fichiers accessibles au processus vulnérable.
- INCIBE situe également ce problème dans les microservices, conteneurs, cloud, API REST et applications avec IA.
- Les techniques SAST, DAST et tests de pénétration aident à détecter ces vulnérabilités avant leur déploiement en production.
- Canonicaliser les chemins, utiliser des listes blanches (allowlists) et appliquer le principe du moindre privilège sont parmi les principales mesures de défense.
L’origine du problème est une problématique connue pour tout développeur : recevoir un paramètre, l’utiliser pour construire un chemin, puis y accéder sans vérifier adéquatement la destination finale. Une fonctionnalité apparemment inoffensive telle que le téléchargement de documents, le chargement d’images, l’importation de fichiers ou la sélection de modèles peut ainsi devenir un point d’entrée malveillant.
L’étude d’INCIBE-CERT rappelle que le Path Traversal figure dans la classification CWE de MITRE et est lié aux problèmes de contrôle d’accès référencés par OWASP. La persistance de cette vulnérabilité prouve que la modernisation de l’architecture ne supprime pas automatiquement les erreurs fondamentales de programmation.
De ../ à l’accès à des fichiers hors du répertoire autorisé
L’exemple classique reste très utile pour comprendre la faille.
Supposons qu’une application stocke des documents dans /var/www/html/documents/ et reçoit via HTTP le nom du fichier à livrer. Si le programme concatène directement ces deux chaînes, l’utilisateur contrôle une partie du chemin que le système d’exploitation résoudra ensuite.
Sous Unix et Linux, ../ désigne le répertoire supérieur. Plusieurs séquences consécutives peuvent faire sortir un chemin relatif du répertoire prévu. INCIBE nomme cette modalité Path Traversal relatif (CWE-23). Il existe également le Path Traversal absolu (CWE-36), où une route complète est directement introduite.
L’exemple de /etc/passwd est fréquemment utilisé, car il permet de visualiser facilement le problème sur Linux. Si le processus du serveur possède des droits de lecture et que l’application ne contrôle pas correctement le chemin, une requête manipulée pourrait conduire le programme à lire ce fichier au lieu du document prévu.
Cela ne signifie pas que le Path Traversal donne directement un accès root ou une exécution à distance.
Son impact dépend des permissions du processus et des opérations possibles. Le risque augmente lorsque des fichiers exposés contiennent des informations exploitables pour poursuivre l’attaque.
Un fichier .env, par exemple, peut contenir des secrets de l’application. Un fichier de configuration pourrait héberger des identifiants de base de données. Les journaux (logs) peuvent révéler des informations internes, et certains fichiers peuvent exposer des utilisateurs, chemins, services ou paramètres de fonctionnement.
INCIBE envisage également des scénarios avancés tels que l’accès à des informations sensibles, la montée en privilèges, voire, lorsque Path Traversal se combine avec d’autres vulnérabilités, l’exécution de code à distance (RCE).
La distinction est essentielle : le Path Traversal est le mécanisme qui permet de contourner la barrière du système de fichiers ; l’impact final dépend de ce qui se trouve de l’autre côté et des permissions du processus.
Cloud, conteneurs et IA n’éliminent pas le problème
La partie la plus récente du rapport apparaît lorsque INCIBE sort du contexte d’une application web classique.
L’organisme pointe explicitement microservices, conteneurs, plateformes cloud, API REST et solutions d’intelligence artificielle comme de nouveaux environnements où la gestion correcte des chemins reste cruciale.
La logique est simple : malgré l’évolution de l’architecture, les applications utilisent encore des systèmes de fichiers.
Un service d’apprentissage automatique peut nécessiter de localiser des modèles ou des jeux de données. Une plateforme IA peut gérer des points de contrôle (checkpoints), des fichiers temporaires ou des répertoires d’artefacts. Une API peut récupérer des documents stockés localement. Un microservice peut traiter des fichiers téléchargés par une autre composante.
Dès qu’une entrée externe influence directement ou indirectement ces chemins, la surface d’attaque doit être contrôlée.
Les conteneurs introduisent une couche supplémentaire d’isolation, mais ne rendent pas une application vulnérable automatiquement sécurisée. Si un processus compromis peut accéder à certains secrets, volumes montés ou configurations dans son environnement, le Path Traversal peut permettre d’y accéder.
C’est pourquoi INCIBE recommande de limiter le système de fichiers aux ressources strictement nécessaires, d’appliquer le principe du moindre privilège et d’isoler correctement les composants dans des architectures distribuées ou contenues.
Il s’agit d’un principe important dans les architectures cloud native : la mitigation ne devrait pas reposer uniquement sur le code traitant le chemin. Les conséquences peuvent aussi être minimisées en limitant les données que le processus peut lire ou modifier.
Canonicaliser en premier, valider ensuite
Une erreur courante consiste à transformer la protection en une compétition pour détecter des chaînes suspectes.
Bloquer ../ semble suffisant jusqu’à ce que différents encodages, séparateurs, normalisations ou comportements du framework et du système d’exploitation compliquent la tâche.
L’étude évoque, dans le cadre des tests de sécurité, l’utilisation d’encodages URL ou Unicode pour vérifier si ces filtres peuvent être contournés. Elle examine aussi des caractères spéciaux et des techniques historiques de troncature (truncation) contre des contrôles faibles.
Une stratégie plus robuste consiste donc à déterminer d’abord le vrai ressource qui peut être demandée et à canonicaliser le chemin final que le système utilisera.
INCIBE recommande d’utiliser systématiquement des allowlists lorsque cela est possible. Si une application doit fournir un ensemble précis de documents, il est généralement plus sûr de travailler avec des identifiants ou noms préautorisés que d’accepter n’importe quelle chaîne envoyée par le client.
Les listes de refus tentent de reconnaître tout ce qui pourrait être dangereux, tandis que les listes blanches (permit lists) inversent la logique : elles n’autorisent que les entrées connues et sûres à l’avance.
Lorsque le contexte nécessite une plus grande flexibilité dans la gestion des chemins, la canonicalisation devient essentielle.
L’objectif est de convertir le chemin demandé en sa version définitive avant d’autoriser l’accès. Ensuite, il convient de vérifier qu’il demeure à l’intérieur du répertoire autorisé.
Par exemple, une chaîne qui semble partir de /var/www/html/documents/ mais est finalement résolue comme une localisation externe doit être rejetée avant que le fichier ne s’ouvre. INCIBE illustre cela avec la fonction realpath() en PHP, mais ce principe est applicable dans d’autres langages et frameworks.
SAST et DAST peuvent révéler deux facettes d’une même vulnérabilité
L’étude aborde aussi Path Traversal du point de vue du cycle de développement logiciel.
Analyse statique de sécurité des applications (SAST) permet d’examiner le code sans l’exécuter, pour repérer les flux où des données utilisateur peuvent finir par atteindre des opérations sur des fichiers.
Les motifs importants incluent la concaténation directe de chemins ou l’appel à des fonctions d’ouverture ou de lecture avec des arguments dépendant d’entrées externes.
L’analyse dynamique de sécurité (DAST) offre une autre perspective. L’application tourne, et les tests manipulent des paramètres d’URL, des formulaires ou autres entrées pour voir comment le serveur y répond réellement.
INCIBE recommande aussi d’effectuer des tests de pénétration, comme troisième approche, pour évaluer la vulnérabilité dans un contexte plus proche d’une attaque réelle.
Ces trois méthodes se complètent : le SAST permet d’identifier du code à risque avant déploiement, le DAST d’observer le comportement en fonctionnement, et le pentest d’étudier l’interaction avec les permissions, configurations et autres vulnérabilités.
L’étude s’appuie aussi sur des laboratoires de la PortSwigger Web Security Academy et Burp Suite pour illustrer, en environnement contrôlé, des cas de détection et d’exploitation. Par exemple, il est montré comment une fonction de chargement d’images peut finir par retourner un fichier situé hors de la localisation prévue.
Zip Slip : Path Traversal au sein d’archives compressées
Le problème ne requiert pas forcément un paramètre visible dans une URL.
INCIBE évoque Zip Slip, une variante apparaissant lors de l’extraction de fichiers ZIP, TAR, JAR et autres formats compressés.
Chaque fichier dans une archive peut contenir une information sur le chemin d’extraction. Si une application se fie à cela sans le vérifier, une entrée malveillante pourrait tenter d’écrire en dehors du répertoire de destination.
Selon les permissions disponibles, cela pourrait impacter des configurations, bibliothèques, exécutables ou autres ressources.
Malgré la différence de vecteur, INCIBE repère la même erreur fondamentale : ne pas valider correctement une route avant de l’utiliser pour accéder au système de fichiers. La mitigation consiste à résoudre et canoniser la destination, vérifier qu’elle reste dans le répertoire autorisé, et exécuter avec le moindre privilège possible.
Ce vecteur est particulièrement critique dans les services modernes recevant des paquets, datasets, plugins, modèles, sauvegardes ou artefacts produits par d’autres systèmes.
La dernière ligne de défense : les permissions et la surveillance
Un développement sécurisé devrait éviter que la traversée de répertoires ait lieu. Mais, limiter les privilèges réduit l’impact potentiel en cas d’échec.
INCIBE recommande de configurer le serveur web pour restreindre l’accès à certains répertoires, désactiver les fonctionnalités non nécessaires et limiter l’accès du processus uniquement aux ressources indispensables.
Il est aussi conseillé de loguer et de surveiller les accès aux fichiers. Un système SIEM (Security Information and Event Management) peut aider à repérer des comportements anormaux ou des tentatives répétées d’accès à des chemins inattendus.
Path Traversal illustre ainsi un problème fréquent en sécurité logicielle : dans une architecture moderne, les vulnérabilités très anciennes peuvent persister si les données externes sont traitées comme des instructions implicites pour accéder au système.
Cloud, Kubernetes, conteneurs ou IA modifient l’emplacement et le contenu des fichiers, mais la règle fondamentale demeure : une application ne devrait faire confiance à un chemin que parce qu’il a été obtenu par une API apparemment légitime.
Questions fréquentes
Quelle différence existe-t-il entre Path Traversal relatif et absolu ?
Le Path Traversal relatif utilise des références à des répertoires supérieurs pour tenter d’échapper à la localisation prévue. Le Path Traversal absolu tente de fournir directement un chemin complet vers une ressource du système. INCIBE les associe respectivement à CWE-23 et CWE-36.
Un Path Traversal peut-il exister à l’intérieur d’un conteneur ?
Oui. L’isolation peut limiter l’impact, mais une application vulnérable peut toujours accéder à des fichiers disponibles pour son processus dans le conteneur ou dans les ressources montées. INCIBE recommande une validation rigoureuse des chemins, l’isolation et le principe du moindre privilège.
Bloquer la chaîne ../ suffit-il ?
Non. Ce n’est pas une défense suffisante à elle seule. Les chemins peuvent être encodés ou représentés de différentes manières. Il est donc préférable d’utiliser des allowlists, de canonicaliser le chemin et de vérifier qu’il reste dans le répertoire autorisé.
Quelles outils permettent de détecter le Path Traversal ?
INCIBE recommande l’utilisation d’analyses SAST, DAST et de tests de pénétration. En pratique, des outils comme Burp Suite et des laboratoires de la PortSwigger Web Security Academy sont exploités pour analyser des requêtes et réponses dans un environnement contrôlé, identifiant facilement ces vulnérabilités.