Inclusion de fichier locale (LFI)
Quand une application choisit un fichier à afficher d'après un paramètre fourni par l'utilisateur, une mauvaise validation ouvre la porte à la LFI : la lecture de fichiers sensibles du serveur, parfois jusqu'à l'exécution de code.
Qu'est-ce qu'une LFI ?
De nombreux sites déterminent la page à servir à partir d'un paramètre (par exemple ?page=apropos). Si l'application inclut le fichier correspondant sans contrôle, un attaquant peut manipuler ce paramètre pour pointer vers d'autres fichiers du serveur, d'où le nom d'« inclusion de fichier locale ».
Il peut alors lire des fichiers de configuration, des journaux, voire des secrets. Dans certaines conditions, la LFI peut même conduire à l'exécution de code. C'est un cas d'école du contrôle d'entrée défaillant, voisin du contrôle d'accès défaillant et un classique des tests d'intrusion.
Ce qu'elle permet
Lire des fichiers sensibles
Fichiers de configuration, identifiants, journaux : autant d'informations précieuses pour préparer une attaque plus large.
Remonter l'arborescence
Via des séquences de type « ../ » (path traversal), atteindre des dossiers en dehors de l'emplacement prévu.
Aller jusqu'à l'exécution de code
Combinée à d'autres éléments (journaux, téléversement…), la LFI peut parfois déboucher sur une exécution de code.
Un tremplin
Souvent une première brique : l'information obtenue alimente une intrusion plus profonde.
Une question de confiance dans l'entrée
Comme la plupart des failles web, la LFI naît d'une confiance excessive accordée à une donnée fournie par l'utilisateur, ici un nom de fichier ou un chemin. Le réflexe à acquérir est universel : ne jamais utiliser directement une saisie pour accéder à une ressource sans la valider strictement. C'est le même principe qui protège du téléversement de fichiers dangereux.
Le principe : liste blanche et chemins maîtrisés
La protection repose sur quelques règles simples : ne jamais construire un chemin de fichier directement à partir d'une saisie, recourir à une liste blanche de pages/ressources autorisées (par exemple via un identifiant qui correspond à un fichier connu), neutraliser le path traversal (« ../ »), et confiner l'accès à un répertoire dédié. Le tout complété par le moindre privilège et validé par un test d'intrusion.
Se protéger, étape par étape
Bannir les chemins dynamiques
Ne pas composer un chemin de fichier à partir d'une saisie utilisateur brute.
Utiliser une liste blanche
Associer un identifiant fourni à un fichier connu et autorisé, plutôt qu'un nom libre.
Neutraliser le path traversal
Filtrer/normaliser les chemins pour empêcher la remontée d'arborescence (« ../ »).
Confiner l'accès
Restreindre la lecture à un répertoire dédié, hors fichiers système et secrets.
Moindre privilège
Limiter les droits du processus pour réduire ce qui est lisible en cas de faille.
Pourquoi se faire accompagner par BCIT ?
Des tests réalistes
Nous éprouvons vos paramètres de fichiers et chemins pour révéler les LFI exploitables.
Des correctifs applicables
Des recommandations concrètes, adaptées à votre langage et votre architecture.
Une vision d'ensemble
De la sécurité applicative aux audits, toute la chaîne.
Pas encore prêt à échanger ? Découvrez notre diagnostic cybersécurité →
Vos paramètres de fichiers sont-ils sous contrôle ?
Prenons 15 minutes pour évaluer l'exposition de vos applications à la LFI et au path traversal, et définir les correctifs prioritaires.
Inclusion de fichier locale (LFI)
Quand une application choisit un fichier à afficher d'après un paramètre fourni par l'utilisateur, une mauvaise validation ouvre la porte à la LFI : la lecture de fichiers sensibles du serveur, parfois jusqu'à l'exécution de code.
Qu'est-ce qu'une LFI ?
De nombreux sites déterminent la page à servir à partir d'un paramètre (par exemple ?page=apropos). Si l'application inclut le fichier correspondant sans contrôle, un attaquant peut manipuler ce paramètre pour pointer vers d'autres fichiers du serveur, d'où le nom d'« inclusion de fichier locale ».
Il peut alors lire des fichiers de configuration, des journaux, voire des secrets. Dans certaines conditions, la LFI peut même conduire à l'exécution de code. C'est un cas d'école du contrôle d'entrée défaillant, voisin du contrôle d'accès défaillant et un classique des tests d'intrusion.
Ce qu'elle permet
Lire des fichiers sensibles
Fichiers de configuration, identifiants, journaux : autant d'informations précieuses pour préparer une attaque plus large.
Remonter l'arborescence
Via des séquences de type « ../ » (path traversal), atteindre des dossiers en dehors de l'emplacement prévu.
Aller jusqu'à l'exécution de code
Combinée à d'autres éléments (journaux, téléversement…), la LFI peut parfois déboucher sur une exécution de code.
Un tremplin
Souvent une première brique : l'information obtenue alimente une intrusion plus profonde.
Une question de confiance dans l'entrée
Comme la plupart des failles web, la LFI naît d'une confiance excessive accordée à une donnée fournie par l'utilisateur, ici un nom de fichier ou un chemin. Le réflexe à acquérir est universel : ne jamais utiliser directement une saisie pour accéder à une ressource sans la valider strictement. C'est le même principe qui protège du téléversement de fichiers dangereux.
Le principe : liste blanche et chemins maîtrisés
La protection repose sur quelques règles simples : ne jamais construire un chemin de fichier directement à partir d'une saisie, recourir à une liste blanche de pages/ressources autorisées (par exemple via un identifiant qui correspond à un fichier connu), neutraliser le path traversal (« ../ »), et confiner l'accès à un répertoire dédié. Le tout complété par le moindre privilège et validé par un test d'intrusion.
Se protéger, étape par étape
Bannir les chemins dynamiques
Ne pas composer un chemin de fichier à partir d'une saisie utilisateur brute.
Utiliser une liste blanche
Associer un identifiant fourni à un fichier connu et autorisé, plutôt qu'un nom libre.
Neutraliser le path traversal
Filtrer/normaliser les chemins pour empêcher la remontée d'arborescence (« ../ »).
Confiner l'accès
Restreindre la lecture à un répertoire dédié, hors fichiers système et secrets.
Moindre privilège
Limiter les droits du processus pour réduire ce qui est lisible en cas de faille.
Pourquoi se faire accompagner par BCIT ?
Des tests réalistes
Nous éprouvons vos paramètres de fichiers et chemins pour révéler les LFI exploitables.
Des correctifs applicables
Des recommandations concrètes, adaptées à votre langage et votre architecture.
Une vision d'ensemble
De la sécurité applicative aux audits, toute la chaîne.
Pas encore prêt à échanger ? Découvrez notre diagnostic cybersécurité →
Vos paramètres de fichiers sont-ils sous contrôle ?
Prenons 15 minutes pour évaluer l'exposition de vos applications à la LFI et au path traversal, et définir les correctifs prioritaires.