La traversée de chemin, également connue sous le nom de traversée de répertoire, se produit lorsqu'un utilisateur malveillant manipule des données fournies par l'utilisateur pour obtenir un accès non autorisé à des fichiers et à des répertoires. En général, l'attaquant tente d'accéder à des journaux et à des informations d'identification qui se trouvent dans des répertoires différents. La traversée de chemin n'est pas une vulnérabilité nouvelle et a été activement exploitée depuis les années 90, lorsque les serveurs web ont gagné en popularité, beaucoup s'appuyant sur des scripts CGI (Common Gateway Interface) pour exécuter un contenu dynamique côté serveur.
Avec une si longue histoire, le path traversal est-il encore populaire aujourd'hui ? Nous avons mené une étude sur les projets open-source et fermés afin de recueillir des données pour voir si la traversée de chemin était courante en 2024 et si nous nous améliorons, Spoilers nous ne le faisonspas.
Exemple de traversée de chemin
Comment fonctionne exactement la traversée de chemin ? Prenons un exemple simple.
Dans cette application simple, un utilisateur reçoit un fichier à télécharger via une variable dans l'URL.
Un simple code Python en arrière-plan gère la demande.
import os
def download_file(file) :
base_directory = "/var/www/files"
file_path = os.path.join(base_directory, file)
if os.path.exists(file_path) :
with open(file_path, 'rb') as f :
return f.read()
else :
return "File not found"
Maintenant que la variable est fournie dans l'URL, nous pouvons la changer en quelque chose comme ceci file=../../../../etc/passwd
Dans ce cas, l'attaquant utilise l'option ../../ pour remonter la structure des répertoires jusqu'au niveau de la racine du système et accéder au fichier transmis, ce qui pourrait lui permettre d'accéder à des informations sensibles.
Si vous voulez voir comment cette méthode peut être sécurisée, faites défiler vers le bas jusqu'au contenu bonus.
Dans les scénarios plus complexes impliquant plusieurs couches de répertoires ou de caractères codés (par exemple, le %2e%2e%2f), les attaquants peuvent contourner les filtres de base et obtenir un accès plus profond au système de fichiers.Traversée du chemin par les chiffres
- 2,7 % de toutes les vulnérabilités trouvées dans des projets open-source en 2024 jusqu'à présent étaient des traversées de chemin.
- 3,5 % pour les projets à code source fermé !
- Une augmentation du nombre total de vulnérabilités de traversée de chemin dans les projets open-source de 742 (2023) à 1 000 attendues (2024).
- En pourcentage de toutes les vulnérabilités, la traversée de chemin est de plus en plus courante, avec une augmentation massive de 85 % des projets à code source fermé.
Notre recherche s'est concentrée sur l'étude des projets à code source ouvert et à code source fermé afin de déterminer combien d'entre eux contenaient des vulnérabilités de traversée de chemin.
Dans l'ensemble, le nombre de vulnérabilités de traversée de chemin est inférieur à d'autres vulnérabilités que nous avons étudiées, telles que les injections de commande ou les injections SQL. Mais si l'on considère que cette vulnérabilité peut être très dangereuse et qu'il existe des solutions bien documentées pour l'éviter, il est alarmant de voir les chiffres aussi élevés. Il est encore plus alarmant de voir que les tendances pour cette vulnérabilité vont dans la mauvaise direction. f
Projets Open Source
Dans les projets open-source, la traversée de chemin représentait 2,6 % de toutes les vulnérabilités signalées en 2023. Ce chiffre a légèrement augmenté en 2024, passant à 2,75 %. Bien que cette augmentation puisse sembler marginale à première vue, elle souligne les défis permanents que pose la sécurisation des logiciels open-source contre les vulnérabilités les plus simples.
Projets à source fermée
La tendance la plus notable a été observée dans les projets à code source fermé, où les incidents de traversée de chemin sont passés de 1,9 % en 2023 à 3,5 % en 2024, soit une augmentation substantielle de 85 % qui met en évidence une tendance alarmante de ce type de vulnérabilité.
Les mauvaises nouvelles ne s'arrêtent malheureusement pas là. Nous constatons toujours une augmentation du nombre global de vulnérabilités signalées dans les projets open-source. Le nombre total de vulnérabilités par injection signalées dans les projets open-source est passé de 742 en 2023 à 917 jusqu'à présent en 2024 (on s'attend à ce qu'il atteigne 1 000).
Empêcher le franchissement des chemins d'accès
La prévention des vulnérabilités liées à l'injection de commandes nécessite une approche à multiples facettes :
Validation des entrées
- Assainissement des entrées utilisateur: Supprimer ou coder les caractères dangereux tels que
../,..\,..%2fou d'autres variations. - Approche par liste d'autorisation: Définir un ensemble strict d'entrées autorisées (par exemple, des noms de fichiers ou des chemins d'accès) et rejeter tout ce qui ne figure pas sur cette liste.
Restreindre l'accès aux fichiers
- Utiliser une prison chroot ou un bac à sable: Limiter l'accès aux fichiers de l'application à un répertoire restreint, en veillant à ce qu'elle ne puisse pas aller au-delà de l'arborescence prévue.
- Définir les répertoires racines: Définir des répertoires de base et s'assurer que tous les chemins d'accès sont relatifs à ces répertoires. Utilisez des API ou des frameworks qui appliquent cette règle, tels que :
java.nio.file.Paths.get("baseDir").resolve(userInput).normalize()en Java.os.path.realpath()etos.path.commonpath()en Python.
Accès sécurisé aux fichiers
- Utiliser des méthodes d'accès aux fichiers sécurisées fournies par des bibliothèques ou des frameworks modernes:En Java, utiliser
Files.newInputStream()ouFiles.newBufferedReader()pour une manipulation sûre des fichiers.
En PythonPour cela, assurez-vous de valider les chemins d'accès aux fichiers avant d'y accéder.
Restrictions de l'environnement d'utilisation
- Fixer des restrictions autorisations du système de fichiers:S'assurer que l'application ne dispose que des privilèges minimums requis.
Interdire l'accès aux répertoires sensibles (par exemple,/etc,/var,/usret les répertoires personnels des utilisateurs). - Désactiver les fonctions inutiles des serveurs web ou des frameworks (par exemple, le suivi des liens symboliques).
Tests automatisés
- Utilisez des outils comme Aikido pour analyser votre code source et votre application afin de découvrir ces vulnérabilités.
- Les outils SAST et DAST doivent être utilisés conjointement avec l'analyse du domaine et la sécurité de l'informatique en nuage pour s'assurer qu'il n'existe pas de vulnérabilités de traversée de chemin cachées.
Utiliser un pare-feu intégré à l'application
- L'une des meilleures défenses contre les attaques par injection est un pare-feu intégré à l'application , capable d'intercepter et de bloquer les commandes malveillantes.
La voie à suivre
La traversée de chemin est une vulnérabilité présente depuis le début des applications web et, bien qu'elle soit souvent assez simple, elle peut aussi être très dévastatrice. C'est pourquoi il est très préoccupant de constater qu'un pourcentage aussi élevé de projets est encore confronté à ce type de problèmes. Bien que 3,5 % ne semble pas être un chiffre élevé, il est tout à fait remarquable qu'il gagne en popularité en dépit de sa menace continue et bien documentée.
La traversée de chemin n'est pas une vulnérabilité qui va disparaître, mais la bonne nouvelle est qu'il existe des moyens clairs de trouver ces vulnérabilités dans notre application et de remédier à tous les problèmes que nous trouvons.
Contenu bonus
Incidents réels
Ces dernières années, plusieurs brèches ou vulnérabilités très médiatisées ont impliqué la traversée d'un chemin, soit comme point d'entrée principal, soit comme élément d'une chaîne de vulnérabilités
Exploit Microsoft IIS Unicode (2001)
L'un des premiers exploits de traversée de chemin très médiatisés ciblant les serveurs Microsoft IIS. Les attaquants utilisaient des chemins encodés pour contourner les mécanismes de validation (par exemple, en utilisant des %c0%af représenter /). Cela leur a permis d'accéder à des fichiers situés en dehors du répertoire racine du site web et de les exécuter.
Cela a permis de déployer des logiciels malveillants et de défigurer de nombreux sites web.
Traversée du chemin VPN de Fortinet (2019)
Le VPN SSL de Fortinet présente une vulnérabilité de traversée de répertoire (CVE-2018-13379). Les attaquants ont exploité cette faille pour accéder à des fichiers système sensibles, tels que les mots de passe en clair des utilisateurs du VPN.
Des milliers d'identifiants VPN ont été divulgués en ligne, exposant les organisations à des accès non autorisés et à d'autres attaques.
Faille de Capital One (2019)
Ce qui s'est passé: Bien que la cause principale soit une vulnérabilité SSRF, l'attaquant a également exploité la traversée de répertoire en accédant aux métadonnées des seaux AWS S3. L'attaquant a exploité des configurations erronées pour récupérer des fichiers de configuration qui auraient dû être inaccessibles.
Les données personnelles de 106 millions de demandeurs de cartes de crédit ont ainsi été exposées.
Traversée de chemin dans le tableau de bord de Kubernetes (2020)
Le tableau de bord Kubernetes présentait une faille de traversée de répertoire (CVE-2020-8563). Les attaquants l'exploitent pour lire des fichiers sensibles dans le conteneur, y compris les secrets stockés dans le répertoire /etc.
.svg)
.jpg)
.jpg)
.jpg)
.jpg)
