Quand les téléchargements de fichiers se transforment en accès aux fichiers
Un seul gestionnaire de téléchargement non sécurisé peut ouvrir la voie à une attaque par traversée de répertoire complète et à une vulnérabilité lors du téléchargement de fichiers. Lorsque les développeurs concatènent directement les noms de fichiers avec les chemins de téléchargement, Les attaquants peuvent soumettre des noms de fichiers malveillants comme ../../etc/passwd pour sortir des répertoires et accéder aux fichiers sensibles. Ce type de traversée de répertoire transforme une simple API de téléchargement en une puissante faille d'accès aux fichiers, notamment lorsque l'application s'exécute avec des autorisations élevées.
⚠️Exemple non sécurisé, à des fins pédagogiques uniquement. Ne pas utiliser en production.
// Vulnerable upload handler, file upload vulnerability
[HttpPost("/upload")]
public async Task<IActionResult> Upload(IFormFile file)
{
var path = Path.Combine("uploads/", file.FileName); // No validation
using var stream = new FileStream(path, FileMode.Create);
await file.CopyToAsync(stream);
return Ok("File uploaded!");
}
Un attaquant peut télécharger un fichier nommé ../../web.config pour écraser ou lire des fichiers protégés, une attaque classique par traversée de répertoire.
Version sécurisée :
// Safe upload with validation and canonicalization
[HttpPost("/upload")]
public async Task<IActionResult> Upload(IFormFile file)
{
var fileName = Path.GetFileName(file.FileName); // strip directories
var targetDir = Path.GetFullPath("uploads/");
var safePath = Path.Combine(targetDir, fileName);
if (!safePath.StartsWith(targetDir))
return BadRequest("Invalid file path");
using var stream = new FileStream(safePath, FileMode.Create);
await file.CopyToAsync(stream);
return Ok("File securely uploaded!");
}
Note pédagogique : Toujours canoniser les chemins avec Chemin.ObtenirCheminComplet() et vérifiez que le résultat reste bien dans votre répertoire de téléchargement. Ne faites jamais confiance à un fichier.NomDeFichier .
Erreurs de développement permettant le parcours de chemin
La plupart des vulnérabilités liées au téléchargement de fichiers et entraînant des violations de répertoires proviennent d'un code écrit à la hâte et d'une validation insuffisante. Voici quelques erreurs courantes commises par les développeurs :
- Concaténation directe des entrées utilisateur dans les chemins du système de fichiers
- Confiant Content-Type ou la validation de l'extension seule
- Ignorer la normalisation des chemins avant l'enregistrement
Réutilisation des dossiers temporaires entre les requêtes ou les microservices
⚠️Exemple non sécurisé, à des fins pédagogiques uniquement. Ne pas utiliser en production.
# Flask example vulnerable to path traversal attack
@app.route('/upload', methods=['POST'])
def upload():
file = request.files['file']
file.save('uploads/' + file.filename)
return 'Uploaded'
Les attaquants peuvent contourner cette simple concaténation pour parcourir les répertoires (../../app.py) et écrire ou écraser des fichiers arbitraires. Version sécurisée :
# Safe file upload validation
from werkzeug.utils import secure_filename
@app.route('/upload', methods=['POST'])
def upload():
file = request.files['file']
name = secure_filename(file.filename)
path = os.path.join('uploads', name)
file.save(path)
return 'Securely uploaded'
Note pédagogique : Utilisez les fonctions d'assistance fournies par le framework, comme nom_de_fichier_sécurisé et appliquez la liste des extensions autorisées. Ne concaténez jamais manuellement les entrées dans les chemins de fichiers.
Exploitation dans le réel Pipelineet microservices
Les attaques par traversée de répertoire ne se produisent pas uniquement sur les points d'accès publics. Elles apparaissent souvent à l'intérieur des réseaux. CI/CD systèmes, référentiels d'artefacts ou microservices qui gèrent les fichiers téléchargés. Par exemple, une vulnérabilité de téléchargement de fichiers dans un gestionnaire d'artefacts de compilation peut permettre à un attaquant d'écraser les scripts de compilation ou injecter des fichiers malveillants dans les runners partagés.
⚠️Exemple non sécurisé, à des fins pédagogiques uniquement. Ne pas utiliser en production.
# Never expose real tokens, credentials, or internal URLs in pipelines
- name: Store build artifact
run: cp $UPLOAD_PATH/$FILENAME /var/artifacts/$FILENAME
If $NOM DE FICHIER n'est pas validé, un fabriqué ../../../etc/passwd Cette valeur peut écraser des fichiers système critiques lors du déploiement, ce qui constitue une véritable attaque par traversée de répertoire. Version sécurisée :
# Safer artifact storage guardrail
- name: Store build artifact securely
run: |
SAFE_NAME=$(basename "$FILENAME")
cp "$UPLOAD_PATH/$SAFE_NAME" /var/artifacts/"$SAFE_NAME"
Note pédagogique : In pipelines, nettoyez toutes les variables de chemin dynamiques. Limitez les opérations d'écriture aux répertoires contrôlés afin d'éviter les fuites de données du système de fichiers lors des compilations ou des déploiements.
Prévention du parcours de chemin dans la logique de téléchargement
Pour limiter les risques liés au parcours de fichiers, il est essentiel de procéder à une validation et une isolation rigoureuses des entrées. Traitez d'emblée les noms de fichiers et les chemins d'accès comme des données non fiables, notamment lors du traitement de fichiers téléchargés.
Pratiques d'excellence
- Normaliser et canoniser tous les chemins avant de les utiliser.
- Restreindre les téléchargements vers un répertoire dédié en dehors de la racine web.
- Appliquer les listes blanches pour les extensions de fichiers et les types MIME.
- Ne réutilisez jamais les dossiers temporaires. entre les sessions ou les utilisateurs.
- Utilisez le stockage conteneurisé pour les fichiers téléchargés, lorsque cela est possible.
Mini liste de contrôle préventive
- Validez chaque nom de fichier avec Chemin.ObtenirNomDuFichier() ou équivalent.
- Résolvez les chemins complets et vérifiez les limites des répertoires.
- Appliquer les listes d'extensions et les listes d'autorisation MIME.
- Utilisez des dossiers de téléchargement distincts par utilisateur ou par session.
- Inclure la numérisation et la validation des chargements dans CI/CD Des tests.
Note pédagogique : Chaque gestionnaire de téléchargement de fichiers représente une vulnérabilité potentielle pour les attaques par traversée de répertoire. Mettez en place une défense en profondeur en validant, isolant et analysant l'ensemble du code de gestion des fichiers.
Comment Xygeni détecte et bloque les flux de téléchargement non sécurisés
Xygéni Code Security analyse bases de code et pipelines pour détecter les modèles de parcours de chemin avant qu'ils n'atteignent la production. Il signale les concaténations de chemins non sécurisées, les erreurs de canonisation et les opérations de fichiers dangereuses, aussi bien dans le code que dans les fichiers. CI/CD scripts.
Extrait de code fonctionnel, avec garde-fous :
# Secure enforcement with Xygeni
- name: Enforce secure upload and path handling
run: dotnet xygeni enforce --rules uploads,path,security --fail-on-risk
Note pédagogique : Intégration Xygéni dans votre pipeline garantit que les vulnérabilités liées au téléchargement de fichiers et les attaques par traversée de répertoire sont détectées automatiquement lors de la validation de la compilation.
Combler le fossé : Prévenir votre prochaine attaque par traversée de chemin
Une simple faille de traversée de répertoire dans un point de terminaison de téléchargement de fichiers peut donner aux attaquants accès au système de fichiers de votre serveur. Vérifiez les gestionnaires de téléchargement pour détecter les concaténations non sécurisées, normalisez tous les chemins d'accès et ne faites jamais confiance aux noms de fichiers contrôlés par l'utilisateur. Ajouter outils d'analyse des vulnérabilités comme Xygeni Code Security à ta DevSecOps pipeline pour détecter les attaques par traversée de répertoire et les vulnérabilités de téléchargement de fichiers avant leur envoi. En matière de sécurité, chaque fichier enregistré doit être considéré comme du code exécuté !
