Traversée de chemin : lire des fichiers interdits

Le principe

Beaucoup de sites ouvrent un fichier dont le nom dépend d’un paramètre : app.exemple.fr/telecharger?file=guide.pdf. En théorie, on ne sert que des fichiers du dossier prévu.

Mais si le site colle bêtement le nom fourni dans un chemin, l’attaquant écrit ../../../../etc/passwd. Chaque ../ remonte d’un dossier. Avec assez de « remontées », il sort du dossier public et atteint des fichiers système.

Ce qu’un attaquant y gagne

Fichiers de configuration, mots de passe en clair, clés d’API, code source : tout ce qui traîne sur le serveur devient lisible. Sur certaines plateformes, cela peut même mener à l’exécution de code (via l’empoisonnement de logs ou des wrappers).

C’est classé dans la catégorie A01:2021 – Contrôle d’accès défaillant de l’OWASP, parce que la faille consiste à accéder à ce qui devrait rester hors de portée.

Comment se protéger

Idéalement, ne construisez jamais un chemin de fichier à partir du texte du visiteur. Faites correspondre un identifiant à un fichier côté serveur (1 → guide.pdf) et refusez tout le reste.

Si vous devez accepter un nom, gardez seulement le nom de base (basename), interdisez « ../ » et les chemins absolus, puis vérifiez que le chemin résolu reste bien à l’intérieur du dossier autorisé. Rangez les secrets hors de la racine web.

La subtilité de la détection

Cette faille est souvent « aveugle » : le site n’affiche pas le fichier, mais se comporte différemment selon qu’il existe ou non. SauronSec compare la réponse pour un fichier système réel et pour un fichier inexistant de même forme.

Une différence stable et reproductible prouve que l’application résout bien le chemin fourni — sans jamais lire ni exfiltrer le moindre contenu. Détection, pas exploitation : c’est la limite non destructive que nous tenons par principe.