Path Traversal : comprendre et prévenir

Auteur : Rédaction Domeny.ForSale Publié le 21.10.2026

En bref : Path Traversal est une faille de sécurité qui permet, par l’intermédiaire d’une application, d’accéder à des fichiers situés hors du répertoire prévu pour traiter une requête donnée. On l’associe le plus souvent à la lecture de fichiers auxquels l’utilisateur ne devrait pas avoir accès, mais elle peut aussi permettre de les modifier ou de les supprimer si l’application propose des fonctions d’écriture ou de suppression. Le problème survient lorsque l’application utilise les données fournies par l’utilisateur dans un chemin de fichier sans vérifier efficacement où ce chemin mène.

Que signifie sortir du répertoire prévu ?

Un chemin est l’adresse d’un fichier dans le système de fichiers, par exemple /srv/application/documents/instrukcja.pdf. Une application de mise à disposition de documents ne devrait autoriser le téléchargement que depuis un emplacement défini, et non donner accès à n’importe quel fichier du serveur.

Path Traversal, également appelé directory traversal ou dot-dot-slash, consiste à franchir cette limite. Le nom dot-dot-slash, littéralement « point-point-barre oblique », renvoie à la notation ../ : les deux points désignent le répertoire parent, tandis que la barre oblique sépare les éléments du chemin. Utilisée de manière appropriée, cette séquence peut donc diriger une opération hors du dossier autorisé.

On peut comparer cela à un guichet de remise de documents. Le client doit fournir un numéro de document, puis l’employé le récupère dans la bonne armoire. La faille apparaît lorsque l’employé accepte, à la place du numéro, une instruction du type : « quitte cette armoire, va dans la pièce voisine et prends le fichier indiqué ».

Exemple : télécharger un document à partir de son nom

Supposons que l’application conserve des documents publics dans le répertoire /srv/application/documents/. L’utilisateur choisit un fichier et le navigateur envoie la requête suivante :

/telecharger?fichier=instrukcja.pdf

Si le programme ajoute sans vérification la valeur du paramètre fichier au chemin du répertoire des documents, il obtient /srv/application/documents/instrukcja.pdf. Avec un simple nom de fichier, tout semble correct. Le problème se révèle lorsqu’on fournit une valeur contenant un passage vers le répertoire parent :

/telecharger?fichier=../konfiguracja.env

Le chemin ainsi construit, /srv/application/documents/../konfiguracja.env, désigne /srv/application/konfiguracja.env, un fichier situé hors du répertoire des documents. Si l’application peut le lire et en renvoie le contenu, des données sont divulguées.

Cet exemple illustre le mécanisme, sans garantir la réussite d’une attaque. Le fichier doit exister, le processus de l’application doit pouvoir y accéder et le traitement de la requête doit permettre d’exploiter le chemin fourni. Ce comportement ne doit être testé que dans votre propre environnement ou avec une autorisation explicite de procéder à des tests.

Quels dommages Path Traversal peut-il causer ?

Les conséquences dépendent avant tout de l’opération effectuée par la fonction vulnérable et des droits dont dispose l’application dans le système d’exploitation.

Lecture de fichiers : une fonction de téléchargement peut révéler la configuration, des données utilisateur, des sauvegardes ou des identifiants d’accès.
Écriture et écrasement : un mécanisme d’écriture vulnérable peut créer un fichier hors du répertoire cible ou modifier un fichier existant.
Suppression : une fonction de suppression de fichiers peut effacer des ressources que l’utilisateur ne devrait pas pouvoir désigner.

Dans certaines conditions, l’écrasement de la configuration ou le dépôt d’un fichier exécuté par le serveur peut permettre de compromettre davantage l’application. Path Traversal ne donne toutefois pas automatiquement la possibilité d’exécuter du code ni un accès complet au serveur. Sa portée est notamment limitée par les droits du processus et les fonctions disponibles dans l’application.

La faille ne concerne pas uniquement les adresses visibles dans le navigateur. Les données qui influencent le chemin peuvent aussi provenir d’un formulaire, d’une requête API, du nom d’un fichier envoyé ou d’une entrée dans une archive en cours d’extraction.

Comment réduire efficacement le risque

La solution la plus sûre consiste à éviter que l’utilisateur indique lui-même un chemin. Au lieu d’accepter un nom ou un emplacement de fichier, l’application peut recevoir un identifiant de document, par exemple 482, puis retrouver elle-même le fichier associé. Elle doit également vérifier que cet utilisateur a le droit de le télécharger : l’identifiant ne constitue pas, à lui seul, une protection.

S’il est nécessaire d’accepter des chemins, la protection doit comporter plusieurs éléments :

Des données d’entrée strictement encadrées. Si la fonction n’a besoin que d’un nom de fichier, elle ne doit pas accepter un chemin complet. Les noms et extensions autorisés doivent se limiter aux besoins réels.
La vérification de l’emplacement final. Après avoir pris en compte les règles du système de fichiers, l’application doit confirmer que la cible se trouve toujours dans le répertoire autorisé. Il faut pour cela utiliser des fonctions adaptées à la manipulation des chemins, et non simplement comparer le début de deux chaînes de caractères.
La prise en compte des liens symboliques. Un lien symbolique renvoie vers un autre emplacement du système de fichiers. Un fichier apparemment situé dans le dossier autorisé peut ainsi pointer vers l’extérieur.
Des droits minimaux. Le processus qui met les documents à disposition ne doit pas avoir accès à des données inutiles, ni disposer de droits d’écriture là où la lecture suffit.

Supprimer simplement la séquence ../ ne constitue pas une protection suffisante. Les différences de séparateurs, d’encodage et d’ordre de traitement des données peuvent conduire le filtre et le système de fichiers à interpréter différemment une même valeur. La vérification doit correspondre à la manière dont l’application ouvre réellement le fichier.

Par où commencer pour vérifier l’application ?

Passez en revue les fonctions de téléchargement, d’envoi, de suppression et d’extraction de fichiers. Pour chacune, déterminez si l’utilisateur peut influencer le chemin, quel répertoire est autorisé et si le programme vérifie la destination finale de l’opération. Les tests doivent couvrir aussi bien les tentatives de sortie du répertoire que les requêtes ordinaires et valides.

Si vous soupçonnez une exploitation de la faille, corriger le code peut ne pas suffire. Il faut déterminer quels fichiers étaient accessibles, examiner les journaux et, si des identifiants d’accès ont pu être divulgués, remplacer les mots de passe ou les clés concernés. La première étape concrète consiste à repérer précisément l’endroit où les données de l’utilisateur deviennent un chemin de fichier.

Voir aussi : Qu’est-ce qu’Apache ?