Path Traversal — Vue d'ensemble

Qu'est-ce que le path traversal#

Le path traversal (CWE-22) est une vulnérabilité dans laquelle une application construit un chemin du système de fichiers à partir d'une entrée contrôlée par l'utilisateur sans contraindre adéquatement l'endroit où ce chemin peut se résoudre. L'attaquant insère des séquences ../ — ou leurs équivalents encodés — pour naviguer vers le haut au-delà du répertoire de base prévu, atteignant des fichiers que l'application n'avait jamais prévu d'exposer. Sous OWASP A01:2021 (Broken Access Control), cela représente un échec à appliquer le principe de moindre privilège au niveau du système de fichiers.

La vulnérabilité apparaît partout où le code côté serveur construit un chemin à partir d'entrées externes : endpoints de téléchargement de fichiers, chargeurs de templates, serveurs d'images, visualiseurs de logs, générateurs de documents et installateurs de plugins. Une augmentation de 85 % d'une année sur l'autre de la prévalence dans les projets à code fermé (de 1,9 % à 3,5 % de tous les findings) issue de l'analyse Aikido 2024 montre que la surface d'attaque est en croissance. Plusieurs entrées CISA KEV en 2024 confirment une exploitation active à grande échelle.

Le path traversal se distingue du SSRF, qui manipule la résolution d'URL pour atteindre des services réseau internes. Les deux primitives se combinent parfois : urllib.parse.urljoin(base, "/etc/passwd") ignore silencieusement la base quand l'entrée utilisateur commence par /, créant une primitive de path traversal dans du code de récupération d'URL (CVE-2026-32871, FastMCP, CVSS 9.8).

Comment ça fonctionne#

La vulnérabilité a une seule cause racine structurelle : une application concatène un répertoire de base fixe avec une entrée utilisateur et passe le résultat à une fonction du système de fichiers sans d'abord vérifier que le chemin canonique résolu reste dans la base.

Cinq étapes d'exploitation :

1. L'attaquant identifie un paramètre alimentant une opération du système de fichiers : file=, path=, template=, page=, include=, doc=, resource=.
2. L'attaquant soumet une séquence de traversée ciblant un fichier à haute valeur (../../etc/passwd).
3. L'application concatène le répertoire de base avec l'entrée sans validation canonique.
4. L'OS résout les segments .., s'échappant du répertoire prévu.
5. Le système de fichiers retourne le fichier cible ; l'application retourne son contenu dans la réponse HTTP.

Les marqueurs de confirmation diffèrent selon la cible. /etc/passwd retourne des lignes correspondant à root:x:0:0:. /proc/self/environ expose les variables d'environnement d'exécution qui contiennent fréquemment des valeurs AWS_SECRET_ACCESS_KEY, DATABASE_URL et API_KEY. WEB-INF/web.xml retourne du XML contenant <web-app.

Variantes d'attaque#

Chaînes d'escalade LFI vers RCE#

Trois chaînes d'escalade convertissent systématiquement les lectures par path traversal en exécution de code à distance :

Empoisonnement de logs : injecter du code PHP dans les logs d'accès du serveur via une requête User-Agent: <?php system($_GET['cmd']); ?> forgée. Quand le fichier log est ensuite inclus via la LFI, l'interpréteur PHP exécute le payload injecté. Logs cibles : /var/log/apache2/access.log, /var/log/nginx/access.log, /var/log/auth.log, /proc/self/fd/2.

Chaînes de filtres PHP : php://filter/convert.base64-encode/resource=index.php retourne le code source PHP encodé en base64 sans nécessiter aucun accès en écriture. Les techniques avancées de chaînes de filtres (php_filter_chain_generator de Charles Fol) construisent des payloads PHP arbitraires ciblant /dev/null, réalisant du RCE non authentifié depuis une LFI sans upload de fichier requis.

ZIP slip : les archives malveillantes contiennent des entrées avec des séquences de traversée dans les noms de fichiers (../../var/www/html/shell.php). Une extraction naïve écrit le webshell dans le document root. CVE-2024-1708 (ConnectWise ScreenConnect, CVSS 8.4) chaîné avec le contournement d'authentification CVE-2024-1709 (CVSS 10.0) pour réaliser du RCE non authentifié en tant que SYSTEM dans les 24 heures suivant la divulgation.

Exemples réels#

CVE-2024-23897 — Jenkins CLI Parser (CVSS 9.8, CISA KEV) : la fonctionnalité expandAtFiles() de la bibliothèque args4j remplaçait les tokens @/path/to/file dans les commandes CLI par le contenu du fichier. Des attaquants non authentifiés lisaient /var/jenkins_home/secrets/master.key et /etc/passwd via HTTP, WebSocket ou SSH. Exploité par le groupe RansomEXX pour compromettre un fournisseur de la National Payments Corporation of India, causant des perturbations de service dans plus de 300 banques. Date limite de correction CISA obligatoire : 9 septembre 2024.

CVE-2024-1708 — ConnectWise ScreenConnect ZIP Slip (CVSS 8.4) : combiné avec le contournement d'authentification CVE-2024-1709 (CVSS 10.0), cela permettait à des attaquants non authentifiés d'écrire des webshells ASPX arbitraires dans le webroot de ScreenConnect. Plusieurs groupes de ransomware ont weaponisé la chaîne dans les 24 heures suivant la divulgation, réalisant un accès SYSTEM.

CVE-2023-2825 — GitLab Path Traversal non authentifié (CVSS 10.0) : lecture de fichier arbitraire via path traversal dans la gestion des URLs de projets imbriqués publics de GitLab CE/EE. Aucune authentification requise. Exposait /etc/passwd, clés privées SSH et tokens d'enregistrement de runner GitLab.

Détection#

Tests manuels#

1. Identifier tous les paramètres qui semblent référencer des fichiers par nom. Se concentrer sur : file=, path=, page=, template=, include=, doc=, resource=, lang=, layout=, theme=, download=.
2. Soumettre ../../etc/passwd (Linux) ou ..\..\Windows\win.ini (Windows) et examiner le corps de la réponse pour des marqueurs de confirmation.
3. Si le payload initial est filtré, tester des variantes encodées : ..%2f..%2fetc%2fpasswd, %2e%2e%2f%2e%2e%2fetc%2fpasswd, ..%252f..%252fetc%252fpasswd.
4. Tester l'injection de chemin absolu sans séquences de traversée : /etc/passwd directement.
5. Ajouter un suffixe null byte : ../../etc/passwd%00.txt — si la réponse diffère, un contournement par null byte est présent.
6. Pour les applications Java, tester ../WEB-INF/web.xml — le marqueur est <web-app.
7. Confirmer avec une recherche de marqueur dans le corps de la réponse : root:x:0:0: (passwd), [fonts] (win.ini), <web-app (web.xml).

Détection automatisée#

BreachVex détecte le path traversal via plusieurs techniques complémentaires : analyse par templates lfi/traversal, fuzzing de paramètres sur un ensemble hiérarchisé de noms de paramètres sujets aux LFI, vérification HTTP directe avec 22 variantes de payload contre des marqueurs de contenu spécifiques à l'OS, et un prouveur LFI étendu avec une porte de contenu à trois critères (HTTP 200 + longueur du corps ≥ 10 octets + correspondance regex du marqueur). Les hits de fuzzing sans confirmation par la porte de contenu sont rétrogradés en findings potentiels de faible sévérité pour supprimer les faux positifs.

Prévention#

Validation canonique du chemin (défense primaire)#

import os
 
BASE_DIR = os.path.realpath("/var/www/app/uploads")
 
def safe_open(filename: str):
    # realpath résout tous les .., symlinks et percent-encoding
    requested = os.path.realpath(os.path.join(BASE_DIR, filename))
    # Le sep final empêche /uploads_backup de passer la vérification /uploads
    if not requested.startswith(BASE_DIR + os.sep):
        raise ValueError("Tentative de path traversal bloquée")
    return open(requested, "rb")

// Java — getCanonicalFile résout .. et les symlinks
File base = new File("/app/uploads").getCanonicalFile();
File requested = new File(base, userInput).getCanonicalFile();
if (!requested.toPath().startsWith(base.toPath())) {
    throw new SecurityException("Tentative de path traversal bloquée");
}

Éviter les noms de fichiers contrôlés par l'utilisateur#

La défense la plus robuste élimine entièrement les noms de fichiers contrôlés par l'utilisateur. Mapper des identifiants opaques vers de vrais chemins de fichiers dans le code côté serveur :

DOCUMENT_MAP = {
    "q1_report": "/app/reports/2025_q1.pdf",
    "q2_report": "/app/reports/2025_q2.pdf",
}
 
def get_document(key: str):
    path = DOCUMENT_MAP.get(key)
    if path is None:
        raise ValueError("Clé de document inconnue")
    return open(path, "rb")

Confinement au niveau OS#

Déployer des chroot jails, des contrôles d'accès mandatoires AppArmor/SELinux ou des systèmes de fichiers de conteneur en lecture seule pour limiter le rayon de blast. Même en cas d'échec de la validation de chemin, un processus correctement confiné ne peut pas accéder aux fichiers en dehors de sa vue restreinte du système de fichiers.

Ressources#

• Path Traversal — Vue d'ensemble pillar
• PortSwigger : File Path Traversal
• OWASP Path Traversal
• CWE-22 : Improper Limitation of Pathname

Sujets connexes#

• Path Traversal de base : séquences ../ classiques, cibles de fichiers Linux, et la chaîne d'empoisonnement de logs LFI-vers-RCE.
• Path Traversal encodé : encodage URL, double encodage, UTF-8 trop long et contournement WAF.
• Injection de chemin absolu : payloads /etc/passwd directs et comportement Python os.path.join.
• Injection null byte : contournement du filtre d'extension %00 en PHP, Java et Go.
• Path traversal Windows : ..\, chemins UNC, Alternate Data Streams et CVE-2024-4577.
• SSRF : le path traversal et le SSRF se combinent quand les chemins fournis par l'utilisateur atteignent du code de récupération d'URL via file:// ou les particularités de urljoin.