Faille LFI (Local File Inclusion) : Détection, exploitation et correction

Votre scanner de vulnérabilités vient de faire mouche et vous affiche une alerte positive sur votre cible ? C’est le moment d’entrer dans le vif du sujet ! Découvrir une faille est une excellente chose, mais savoir l’analyser, vérifier qu’il ne s’agit pas d’un faux positif et mesurer son impact réel à la main est ce qui fera de vous un vrai pentester. Aujourd’hui, nous allons détecter, exploiter et corriger une faille LFI : Local File Inclusion.

Dans ce guide complet, nous allons dépasser le simple stade du clic automatique pour apprendre à valider manuellement une vulnérabilité d’inclusion de fichier (LFI). Vous découvrirez pas à pas le mécanisme caché derrière cette faiblesse web, comment décoder une URL vulnérable et, surtout, comment exploiter éthiquement cette faille pour prouver son existence sans casser le système. Préparez votre environnement de test, on passe à la pratique !

• Passer du scan automatique à l’analyse humaine en apprenant à décoder les alertes de votre outil pour confirmer vos vulnérabilités sans risque d’erreur.
• Maîtriser la logique de la navigation relative pour comprendre exactement comment un serveur interprète vos commandes et pouvoir cibler les fichiers systèmes clés.
• Devenir une force de proposition en découvrant comment transformer une faille critique en un correctif de code robuste basé sur une liste blanche.

Ce tutoriel est dédié à l’apprentissage de la cybersécurité offensive. En tant que formateur, mon objectif est de vous accompagner pas à pas dans la compréhension des mécanismes de détection et de validation de cette vulnérabilité.

Pour des raisons de clarté pédagogique et de sécurité, nous allons étudier ce processus à travers un cas pratique entièrement simulé et maîtrisé : une vulnérabilité de type LFI (Local File Inclusion) sur une application web fictive. On se concentre sur la méthodologie, l’analyse des requêtes et la compréhension des protocoles, dans un cadre strictement éthique et éducatif.

Imaginez la scène : vous lancez un outil de diagnostic sur un site web (dont vous avez l’autorisation écrite de tester la sécurité, bien sûr !), et soudain, un voyant rouge s’allume. Une vulnérabilité est détectée. C’est l’excitation du débutant, rapidement suivie d’un grand point d’interrogation : « Et maintenant, je fais quoi ? »

Découvrir une faille de sécurité n’est que la première étape du travail d’un auditeur. Le véritable défi consiste à comprendre ce que l’outil a trouvé, à vérifier s’il ne s’agit pas d’une fausse alerte (un « faux positif »), et à mesurer son impact réel.

Qu’est-ce qu’une vulnérabilité LFI (Local File Inclusion) ?

Avant de manipuler du code, il est indispensable de comprendre ce que nous cherchons. L’acronyme LFI signifie Local File Inclusion (ou Inclusion de Fichiers Locaux, en bon français).

Le concept vulgarisé

Pour comprendre, faisons une analogie culinaire. Imaginez un site web comme un restaurant où vous ne pouvez pas entrer dans la cuisine. Vous passez commande via un menu. Si vous demandez le « plat numéro 3 », le serveur du restaurant (le code du site) va chercher la recette du plat numéro 3 dans le classeur de la cuisine (le serveur informatique) et vous l’apporte.

Une vulnérabilité LFI apparaît lorsque le serveur fait aveuglément confiance à ce que vous écrivez sur le menu. Si, au lieu de demander le « plat numéro 3 », vous écrivez sur le bon de commande : « Donne-moi le carnet de comptes secrets du patron qui est rangé dans le tiroir du fond », et que le serveur du restaurant s’exécute sans réfléchir, vous venez de réussir une inclusion de fichier local.

En informatique, cela signifie qu’un attaquant détourne un paramètre du site web pour forcer l’application à lire et à afficher un fichier présent sur le serveur auquel il ne devrait jamais avoir accès (comme des fichiers de configuration, des journaux d’activité ou des listes d’utilisateurs).

Il s’agit donc d’une vulnérabilité permettant à un attaquant de lire des fichiers présents sur le serveur via un paramètre mal sécurisé.

Par exemple :

<?php
include($_GET['page']);

Avec une URL :

https://monsite.fr/index.php?page=contact.php

Un attaquant pourrait tenter :

https://monsite.fr/index.php?page=../../../../etc/passwd

• Si le serveur affiche le contenu du fichier système, la faille LFI est présente.

Comment détecter une faille LFI ?

La détection repose sur différentes approches :

1. Tests manuels

La première méthode consiste à repérer les paramètres qui chargent des fichiers :

?page=
?file=
?include=
?template=
?lang=
?view=
?module=
?path=

Puis à injecter des chemins connus :

../../../../etc/passwd

../../../../windows/win.ini

Exemples :

https://site.fr/index.php?page=../../../../etc/passwd

ou

https://site.fr/index.php?file=../../../../windows/win.ini

Les signes révélateurs sont :

• affichage du contenu du fichier
• erreurs PHP contenant un chemin serveur
• message « failed to open stream »
• fuite d’informations sur l’arborescence du serveur.

2. Utiliser Burp Suite

Burp Suite est probablement l’outil le plus utilisé pour rechercher des LFI.

Procédure :

1. Intercepter la requête.
2. Envoyer la requête dans Repeater.
3. Modifier les paramètres suspects.
4. Tester plusieurs payloads.

Exemple :

?page=../../../../etc/passwd
?page=....//....//....//etc/passwd
?page=%2e%2e%2f%2e%2e%2fetc/passwd

L’avantage est de voir immédiatement les différences de réponse.

3. Utiliser ffuf

Ffuf est un excellent outil de fuzzing.

Le fuzzing est une technique de test qui consiste à envoyer automatiquement des milliers de données au hasard, bizarres ou malformées à un programme informatique pour voir si cela le fait bugger, planter ou révéler une faille de sécurité.

Exemple :

ffuf -u "https://site.fr/index.php?page=FUZZ" \
-w lfi.txt

Contenu du fichier :

../../../../etc/passwd
../../../../etc/hosts
../../../../proc/self/environ

Vous pourrez rapidement identifier les réponses anormales.

👉 Pour aller plus loin, consultez notre guide complet pour ffuf, l’outil de fuzzing web.

4. Utiliser Nuclei

Nuclei dispose de nombreux templates spécialisés.

Par exemple :

nuclei -u https://site.fr

ou

nuclei -u https://site.fr -tags lfi

L’outil va rechercher automatiquement des schémas connus de vulnérabilités LFI.

👉 Pour en savoir plus : Nuclei, le guide complet pour débuter en audit de sécurité.

5. Utiliser OWASP ZAP

OWASP ZAP est une alternative gratuite à Burp Suite.

Fonctionnalités utiles :

• Spider du site
• Scan actif
• Fuzzing des paramètres
• Détection de vulnérabilités d’inclusion de fichiers.

Particulièrement intéressant pour les débutants : Découvrez OWASP Zap.

Exploiter une faille LFI : Les fichiers les plus recherchés lors des tests

Dans un contexte d’audit de sécurité autorisé, l’utilisation d’une wordlist LFI est une pratique courante. Plutôt que de tester manuellement quelques fichiers connus, les outils de fuzzing comme ffuf, Burp Suite Intruder ou OWASP ZAP peuvent essayer automatiquement des centaines de chemins de fichiers susceptibles d’être présents sur un serveur Linux ou Windows.

Une wordlist LFI contient généralement des chemins fréquemment ciblés tels que /etc/passwd, /etc/hosts, /proc/self/environ, windows/win.ini, mais aussi des fichiers de configuration, des journaux système ou des fichiers spécifiques à certains CMS.

L’objectif n’est pas de deviner au hasard, mais de vérifier si l’application permet l’accès à des fichiers sensibles situés en dehors du répertoire prévu. Les résultats obtenus peuvent révéler une faille LFI, mais également fournir des informations précieuses sur l’architecture du serveur, le système d’exploitation utilisé ou les technologies installées.

Il existe plusieurs wordlists prêtes à l’emploi, notamment dans le projet SecLists, qui propose des listes dédiées aux tests LFI. Par exemple, avec ffuf, il est possible d’automatiser les essais en utilisant une wordlist adaptée :

ffuf -u "https://site.fr/index.php?page=FUZZ" \
-w lfi-wordlist.txt

Cette approche permet de couvrir un grand nombre de cas en quelques minutes et constitue souvent un excellent complément aux vérifications manuelles réalisées sur les paramètres suspects.

Attention : sur un site qui ne vous appartient pas, tester ces fichiers sans autorisation peut être illégal.

Votre propre wordlist LFI

Pour gagner du temps lors des tests, il est possible de créer votre propre wordlist regroupant les fichiers les plus couramment recherchés sur les systèmes Linux et Windows.

Cette liste n’est qu’un point de départ et peut être enrichie selon le contexte de l’audit.

../../../../etc/passwd
../../../../etc/hosts
../../../../etc/group
../../../../etc/shadow
../../../../proc/version
../../../../proc/self/environ
../../../../proc/self/cmdline
../../../../proc/mounts
../../../../var/log/apache2/access.log
../../../../var/log/apache2/error.log
../../../../var/log/nginx/access.log
../../../../var/log/nginx/error.log
../../../../home/www-data/.bash_history
../../../../root/.bash_history
../../../../windows/win.ini
../../../../windows/system.ini
../../../../windows/system32/drivers/etc/hosts
../../../../boot.ini
../../../../inetpub/logs/LogFiles

Cette mini-wordlist permet de rechercher différents types d’informations : comptes utilisateurs, configuration système, journaux d’activité, variables d’environnement ou encore fichiers de configuration réseau.

Lorsqu’un fichier est accessible alors qu’il ne devrait pas l’être, cela constitue souvent un indicateur fort de la présence d’une vulnérabilité LFI.

Comment se protéger ?

Les bonnes pratiques sont :

$pages = [
    'accueil' => 'pages/accueil.php',
    'contact' => 'pages/contact.php'
];

include($pages[$_GET['page']] ?? 'pages/404.php');

et surtout :

• ne jamais inclure directement une entrée utilisateur
• utiliser une liste blanche
• désactiver allow_url_include 
• limiter les permissions de lecture
• mettre à jour PHP et les CMS
• effectuer régulièrement des audits avec Burp Suite, ZAP ou Nuclei.

À quoi sert la phase de validation ?

Lorsqu’un scanner automatique vous informe qu’une faille LFI existe à un endroit précis, il se base sur des indices textuels ou des codes de réponse reçus. Cependant, les machines peuvent se tromper.

La validation manuelle sert à trois choses essentielles :

1. Éliminer le doute : Confirmer que la faille est bien réelle et exploitable.
2. Comprendre le contexte : Découvrir comment l’application réagit et pourquoi elle est vulnérable.
3. Évaluer le risque : Déterminer la sensibilité des informations qui peuvent être lues (des mots de passe cachés, par exemple).

En tant que professionnel, vous ne pouvez pas vous contenter de copier-coller le rapport d’un outil automatique. Vous devez apporter votre valeur ajoutée humaine en expliquant précisément le mécanisme de la faille.

Anatomie d’une requête vulnérable

Voyons concrètement à quoi ressemble le code d’une application web qui présente cette faiblesse. Très souvent, cela se passe dans la gestion de l’affichage des pages.

Le code côté serveur (Exemple en PHP)

Voici un exemple de code source typique qui génère une vulnérabilité LFI. Ce code prend un paramètre dans l’adresse URL pour charger une page.

<?php
// Exemple de code vulnérable pour notre étude

// On récupère le nom de la page demandé dans l'URL (ex: index.php?page=contact)
$page = $_GET['page'];

// Le développeur inclut directement le fichier demandé sans vérifier son contenu
// C'est ici que réside l'erreur de logique !
include("pages/" . $page);

Pourquoi ce code est-il dangereux ? 

• Le script fait une confiance absolue à la variable $page.

Si l’utilisateur tape index.php?page=about.php, le serveur cherche pages/about.php. Tout fonctionne bien. Mais si l’utilisateur modifie la valeur pour pointer vers un autre endroit du système, le mot-clé include s’exécutera tout de même.

Le mécanisme de la navigation relative

Pour exploiter cette faille architecturalement, les auditeurs utilisent une technique appelée le Directory Traversal (ou traversée de répertoires). Elle repose sur un concept que vous utilisez peut-être déjà sans le savoir : le symbole ../.

Dans la quasi-totalité des systèmes d’exploitation (Linux, Windows, macOS), le symbole .. signifie « remonter d’un dossier en arrière ».

Si l’application cherche un fichier dans pages/, et que nous lui donnons comme instruction :

../../../../etc/passwd

Des formations informatique pour tous !

Débutant ou curieux ? Apprenez le développement web, le référencement, le webmarketing, la bureautique, à maîtriser vos appareils Apple et bien plus encore…

Formateur indépendant, professionnel du web depuis 2006, je vous accompagne pas à pas et en cours particulier, que vous soyez débutant ou que vous souhaitiez progresser. En visio, à votre rythme, et toujours avec pédagogie.

Découvrez mes formations Qui suis-je ?

Le serveur va lire la commande de cette manière :

1. Entrer dans le dossier pages/ (action par défaut du code).
2. Remonter d’un niveau (sortir de pages/).
3. Remonter d’un niveau (arriver à la racine du site).
4. Remonter encore plusieurs fois pour s’assurer d’atteindre la racine absolue du système Linux (/).
5. Descendre dans le dossier etc/ et lire le fichier passwd.

Le fichier /etc/passwd est un fichier standard sur les systèmes Linux qui contient la liste des utilisateurs du système. Il ne contient pas leurs mots de passe, mais sa lecture réussie est la preuve universelle qu’une LFI est fonctionnelle.

Comment corriger ce code PHP ?

Le code précédent est vulnérable car il fait confiance à une donnée contrôlée par l’utilisateur : le paramètre page présent dans l’URL.

Pourquoi ce code est vulnérable ?

Le développeur suppose que l’utilisateur demandera uniquement des pages légitimes :

index.php?page=accueil.php
index.php?page=contact.php

Mais rien n’empêche un attaquant de modifier l’URL :

index.php?page=../../../../etc/passwd

Le code va alors construire :

include("pages/" . "../../../../etc/passwd");

PHP résout automatiquement les ../ et tente de lire :

/etc/passwd

Si les permissions le permettent, le contenu du fichier sera affiché ou traité par l’application.

Le problème fondamental est que l’utilisateur choisit lui-même quel fichier sera inclus.

Première correction : utiliser une liste blanche

La solution la plus simple consiste à définir à l’avance les pages autorisées.

<?php

$pages_autorisees = [
    'accueil' => 'pages/accueil.php',
    'contact' => 'pages/contact.php',
    'services' => 'pages/services.php'
];

$page = $_GET['page'] ?? 'accueil';

if (isset($pages_autorisees[$page])) {
    include($pages_autorisees[$page]);
} else {
    include('pages/404.php');
}

Avec ce système :

index.php?page=contact

fonctionne.

En revanche :

index.php?page=../../../../etc/passwd

ne correspond à aucune entrée de la liste blanche et affichera simplement la page 404.

• Cette solution est la meilleure parce qu’elle inverse la logique.

Avec l’ancienne logique :

Tout est autorisé sauf ce que l'on bloque.

Mais avec la nouvelle logique :

Tout est interdit sauf ce que l'on autorise.

C’est l’un des principes fondamentaux du développement sécurisé.

Deuxième correction : vérifier l’existence du fichier

Même avec une liste blanche, il est conseillé de vérifier que le fichier existe :

<?php

$pages_autorisees = [
    'accueil' => 'pages/accueil.php',
    'contact' => 'pages/contact.php'
];

$page = $_GET['page'] ?? 'accueil';

if (
    isset($pages_autorisees[$page]) &&
    file_exists($pages_autorisees[$page])
) {
    include($pages_autorisees[$page]);
} else {
    include('pages/404.php');
}

Cela évite les erreurs PHP si un fichier est supprimé par accident.

Troisième correction : utiliser un routeur

Sur les projets modernes, on n’utilise généralement plus directement le nom des fichiers dans l’URL.

On utilise plutôt des routes :

/index.php?page=contact
/index.php?page=services
/index.php?page=mentions-legales

Puis une correspondance interne :

$route = [
    'contact' => 'ContactController.php',
    'services' => 'ServicesController.php'
];

L’utilisateur ne connaît jamais le véritable emplacement des fichiers.

Ce qu’il ne faut pas faire

Beaucoup de développeurs débutants tentent ceci :

$page = str_replace('../', '', $_GET['page']);
include('pages/' . $page);

ou :

$page = basename($_GET['page']);
include('pages/' . $page);

Ces protections réduisent certains risques mais ne sont pas suffisantes.

Un attaquant expérimenté trouvera souvent des méthodes de contournement selon la configuration du serveur et la version de PHP.

La règle à retenir

Le vrai correctif n’est pas de filtrer les caractères dangereux.

Le vrai correctif consiste à ne jamais laisser l’utilisateur choisir le fichier à inclure.

La méthode recommandée est donc :

1. définir une liste blanche des pages autorisées ;
2. vérifier que la clé demandée existe ;
3. inclure uniquement les fichiers prédéfinis par le développeur ;
4. afficher une page 404 dans tous les autres cas.

C’est cette approche qui protège efficacement contre les vulnérabilités LFI (Local File Inclusion) et qui est utilisée dans la majorité des applications PHP modernes.

Cas concret : Simulation pas à pas

Passons maintenant à la pratique théorique. Imaginons que notre outil de détection nous ait signalé une anomalie sur l’adresse suivante :

http://cible-fictive.local/view.php?file=welcome.html

Dans un contexte d’audit de sécurité autorisé sur votre propre infrastructure, Nuclei peut détecter certaines vulnérabilités LFI connues grâce à ses templates.

Exemple de commande

Pour scanner une URL précise :

nuclei -u https://site.fr -tags lfi

Ou pour scanner plusieurs URL :

nuclei -l urls.txt -tags lfi

Vous pouvez également lancer tous les templates installés :

nuclei -u https://site.fr

À quoi ressemble une détection ?

L’affichage exact dépend du template utilisé, mais Nuclei indique généralement :

• le template ayant détecté le problème
• l’URL vulnérable
• le niveau de gravité
• parfois l’emplacement du paramètre concerné.

Exemple typique :

[lfi-detect] [http] [high] https://site.fr/index.php?page=../../../../etc/passwd

ou :

[generic-lfi] [http] [high]
https://site.fr/index.php?file=../../../../etc/passwd

Avec les options de verbosité :

nuclei -u https://site.fr -tags lfi -vv

Vous pourriez obtenir quelque chose ressemblant à :

[INF] Templates loaded: 15

[generic-lfi] [http] [high]
https://site.fr/index.php?page=../../../../etc/passwd

Matched-at:
https://site.fr/index.php?page=../../../../etc/passwd

Evidence:
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

Dans cet exemple, le template a identifié des signatures caractéristiques du fichier /etc/passwd, ce qui indique qu’un fichier système a été retourné par l’application.

Ici, Nuclei a injecté automatiquement plusieurs chemins de fichiers connus. Lorsque la réponse du serveur a contenu la chaîne root:x:0:0:, le template a considéré que le fichier /etc/passwd avait été lu avec succès et a signalé une vulnérabilité LFI de niveau élevé.

Comment Nuclei sait qu’il y a une LFI ?

Les templates ne se contentent pas de vérifier un code HTTP 200. Ils recherchent généralement des chaînes caractéristiques :

Pour Linux :

root:x:0:0:
daemon:x:
www-data:

Pour Windows :

[fonts]
[extensions]
for 16-bit app support

correspondant souvent au contenu de :

C:\Windows\win.ini

Éliminer les faux positifs

Voici la méthode rigoureuse pour valider cette découverte.

Étape 1 : Analyse de la structure de l’URL

Nous constatons la présence du paramètre file=. C’est notre point d’entrée potentiel. L’application web semble appeler des fichiers statiques pour les afficher à l’écran.

Étape 2 : Construction du test de validation

Nous allons modifier manuellement l’URL dans notre navigateur web ou via un outil de requêtage pour tenter de sortir de l’arborescence web prévue par le développeur.

Un outil de requêtage est un logiciel permettant d’envoyer des requêtes HTTP à un serveur web et d’analyser les réponses obtenues. Il peut s’agir d’outils graphiques comme Burp Suite ou OWASP ZAP, mais aussi d’outils en ligne de commande comme cURL. Ces outils permettent notamment de modifier facilement les paramètres d’une URL afin de tester le comportement d’une application web.

Nous remplaçons welcome.html par notre séquence de remontée :

http://cible-fictive.local/view.php?file=../../../../etc/passwd

Étape 3 : Interprétation du résultat

Si le site web affiche une page blanche ou une erreur de type 404 Not Found, il est probable que le code soit sécurisé ou que le chemin soit incorrect.

En revanche, si le site affiche à l’écran un texte ressemblant à ceci :

root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin

Félicitations (virtuelles) ! Vous venez de confirmer la vulnérabilité. Vous avez réussi à faire lire au serveur un fichier système interne via l’application web.

---

---

La transition entre la détection automatique et la compréhension manuelle est le fondement même du métier de spécialiste en sécurité informatique. Les outils automatiques sont de formidables accélérateurs de tâches, mais ils ne remplaceront jamais la logique, l’analyse et l’éthique de l’humain.

Pour progresser, l’entraînement est votre meilleur allié. Je vous encourage vivement à installer des environnements de tests légaux et délibérément vulnérables (comme DVWA ou OWASP Juice Shop) sur votre propre machine. Amusez-vous à observer comment les modifications de vos paramètres modifient le comportement du serveur. C’est en forgeant que l’on devient forgeron, et c’est en analysant le code que l’on apprend à le défendre efficacement.