Réussir une local file inclusion : guide pratique

Une vulnérabilité de local file inclusion permet à un attaquant de forcer un serveur web à lire, interpréter ou exposer un fichier qu’il n’aurait jamais dû rendre accessible. Le mécanisme est simple, l’impact peut être dévastateur : lecture de fichiers de configuration, exfiltration de secrets, escalade vers l’exécution de code arbitraire. Ce guide couvre l’identification, la reproduction en environnement contrôlé, la mesure d’impact et la remédiation — sans raccourci ni sensationnalisme.

Local file inclusion : définition, périmètre et différences avec rfi

Une local file inclusion (LFI) est une vulnérabilité qui survient lorsqu’une application web intègre dynamiquement un fichier dans sa réponse en se basant sur une entrée utilisateur, sans valider ni restreindre cette entrée. Le serveur est ainsi piégé pour inclure un fichier indésirable présent localement sur son système de fichiers, sans vérifier la légitimité de la demande. Le résultat peut aller de la simple lecture d’un fichier de configuration à l’exécution de code PHP arbitraire.

Il faut distinguer précisément trois notions souvent confondues :

• Path traversal : technique de navigation dans l’arborescence du système de fichiers via des séquences comme ../. C’est un mécanisme, pas forcément une inclusion.
• LFI : l’attaquant force l’application à inclure un fichier local, c’est-à-dire à l’interpréter ou à en restituer le contenu dans la réponse HTTP.
• RFI (remote file inclusion) : l’attaquant force l’application à inclure un fichier distant, généralement hébergé sur un serveur qu’il contrôle. La RFI nécessite que la directive PHP allow_url_include soit activée, ce qui est désactivé par défaut depuis PHP 5.2.

La RFI est due à l’utilisation d’une entrée fournie par l’utilisateur sans validation adéquate, tout comme la LFI, mais son périmètre d’impact immédiat est plus large : elle peut conduire à l’exécution de code sur le serveur web, à l’exécution de code côté client (JavaScript), au vol ou à la manipulation de données, voire à un déni de service. Les attaques de ce type concernent des langages de script tels que ASP, JSP et PHP.

La LFI reste une vulnérabilité classée dans les principales catégories de l’OWASP (notamment sous A03 Injection et A05 Security Misconfiguration). Des CVE liées à des LFI dans des CMS, des frameworks ou des plugins populaires sont publiées chaque année, ce qui confirme que le problème n’est pas théorique. Comprendre pourquoi ces vulnérabilités apparaissent dans le code est l’étape suivante.

Origines techniques : paramètres, routage et fonctions d’inclusion vulnérables

En PHP, la cause principale d’une LFI est l’utilisation de variables externes non validées — typiquement $_GET, $_POST ou $_COOKIE — passées directement à des fonctions d’inclusion de fichiers. Les fonctions les plus couramment citées comme vecteurs sont include et require, ainsi que leurs variantes include_once et require_once.

Un schéma de code vulnérable typique ressemble à ceci :

L’intention du développeur est de charger un template parmi une liste connue. Mais sans validation, n’importe quelle valeur de page est acceptée. Un attaquant peut passer ../../../etc/passwd%00 pour tenter de lire le fichier /etc/passwd. Le null byte (%00) était historiquement utilisé pour supprimer le suffixe .php ajouté par le code — une technique qui fonctionnait sur les versions de PHP antérieures à 5.3.4, où la gestion des chaînes de caractères en C permettait cette troncature.

Les patterns d’inclusion vulnérables se retrouvent dans plusieurs contextes :

• Systèmes de templates : un paramètre lang ou theme charge un fichier de traduction ou de mise en page.
• Contrôleurs frontaux : un paramètre module ou page route vers un fichier PHP de fonctionnalité.
• Fonctions de prévisualisation ou de téléchargement : un paramètre file ou path construit un chemin vers un fichier à lire.
• Systèmes de plugins : des CMS qui chargent dynamiquement des composants selon un identifiant passé en URL.

La configuration serveur joue également un rôle. La directive PHP allow_url_fopen, si elle est activée, permet à des fonctions de fichiers d’utiliser une URL pour récupérer des données depuis des emplacements distants — ce qui peut faciliter une RFI si l’entrée n’est pas validée. Pour la LFI pure, c’est davantage l’absence de restriction sur open_basedir qui aggrave l’exposition : sans cette directive, PHP peut lire n’importe quel fichier accessible par l’utilisateur système du serveur web.

Les stream wrappers PHP constituent une autre surface d’attaque. PHP expose nativement des protocoles comme php://filter, php://input, data://, zip:// ou phar://. Ces wrappers peuvent être passés comme valeur d’un paramètre d’inclusion pour contourner des filtres naïfs ou pour encoder la sortie. Par exemple, php://filter/convert.base64-encode/resource=index.php retourne le code source d’un fichier PHP encodé en base64, contournant son interprétation et permettant sa lecture.

Ces origines techniques dessinent une surface d’attaque précise. Savoir où chercher dans le code est nécessaire, mais identifier les signaux visibles depuis l’extérieur de l’application est tout aussi important pour un audit en boîte noire.

Signaux de détection : symptômes, erreurs et endpoints à risque

Repérer une LFI potentielle avant même d’injecter quoi que ce soit repose sur l’observation méthodique de l’application. Certains comportements et certains patterns d’URL sont des indicateurs forts qu’une inclusion dynamique est en jeu.

Les paramètres à surveiller en priorité sont ceux dont le nom suggère une référence à un fichier ou à une ressource :

• page, lang, language, template, theme
• file, path, filepath, dir, folder
• view, module, section, include, document
• download, preview, content, layout

Une URL comme https://example.com/ ?module=/etc/passwd est un exemple illustratif classique de ce type d’exposition. La présence d’une extension dans la valeur du paramètre (page=contact.php) est également un signal fort : le code inclut probablement directement la valeur.

Les messages d’erreur PHP sont particulièrement révélateurs. Un message du type Warning: include(pages/inexistant.php): failed to open stream ou No such file or directory confirme qu’une fonction d’inclusion est utilisée et que le chemin passé en paramètre est construit dynamiquement. Même une erreur générique de type 500 peut indiquer un comportement anormal si elle apparaît uniquement lors de la modification du paramètre.

D’autres signaux méritent attention :

• Temps de réponse anormalement long lors de l’injection de chemins vers des fichiers inexistants (timeout de résolution).
• Réponse vide ou tronquée qui diffère du comportement normal.
• Changement de longueur de réponse selon la valeur injectée.
• Headers de réponse qui varient (Content-Type, taille) selon le fichier demandé.

Dans un contexte d’objets connectés ou d’API, les serveurs web servent d’intermédiaires entre un appareil et une application cliente. Des endpoints de type /api/render ?template= ou /device/config ?file= sont des surfaces d’attaque à ne pas négliger lors d’un audit. Des serveurs mal configurés ou insuffisamment sécurisés peuvent permettre à des attaquants de recueillir des données sensibles ou de compromettre le système à distance via ce type de vecteur.

Une fois les endpoints candidats identifiés, il est temps de passer à la phase de test structurée — en environnement autorisé uniquement.

Méthode de test pas à pas : valider une lfi en environnement autorisé

Toute tentative de reproduction d’une LFI doit se faire dans un cadre strictement défini : environnement de laboratoire dédié (machine virtuelle, Docker, plateforme de type DVWA, WebGoat ou bWAPP), ou périmètre explicitement autorisé par un contrat de test d’intrusion signé. Tester sur un système en production sans autorisation écrite est illégal dans la quasi-totalité des juridictions.

Étape 1 — Formuler l’hypothèse : identifier le paramètre suspect, noter la valeur légitime attendue et la réponse normale associée. Documenter l’URL complète, les headers de requête et le code de réponse HTTP de référence.

Étape 2 — Injection minimale : commencer par une valeur neutre qui ne devrait pas exister, comme page=lfi_test_probe. Observer si une erreur PHP apparaît dans la réponse. Si oui, la surface est confirmée.

Étape 3 — Traversal basique : injecter ../../../etc/passwd (sur Linux) ou ../../../windows/win.ini (sur Windows). Vérifier si le contenu du fichier apparaît dans la réponse. Sur Linux, la présence de root:x:0:0: dans la réponse est une preuve irréfutable.

Étape 4 — Variations et profondeur : si le premier essai échoue, tester différentes profondeurs de traversal (../../, ../../../../, jusqu’à ../../../../../../). Le répertoire racine du système de fichiers étant /, une profondeur suffisante atteindra toujours la racine, même depuis un sous-répertoire profond.

Étape 5 — Gestion des encodages : si un filtre bloque la séquence ../, tester les variantes encodées :

• URL encoding : %2e%2e%2f
• Double encoding : %252e%252e%252f
• Encodage Unicode : ..%c0%af (slash Unicode)
• Séparateurs mixtes : ../, .. sur Windows

Étape 6 — Wrappers PHP : tester php://filter/convert.base64-encode/resource=index.php pour récupérer le code source encodé. Décoder le résultat en base64 pour valider la lecture. Ce vecteur contourne les filtres qui bloquent les extensions .php dans le chemin.

Étape 7 — Preuves minimales et réversibles : capturer la requête et la réponse complètes (via Burp Suite ou un proxy équivalent). Ne jamais modifier de fichier sur le système cible. La preuve doit démontrer l’impact sans aggraver la situation.

Cette méthode structurée permet de valider une LFI de manière reproductible et documentée. Les techniques d’exploitation plus avancées s’appuient sur ces bases.

Techniques d’exploitation courantes : path traversal, encodages et contournements

Une fois la surface d’attaque confirmée, les techniques d’exploitation visent à maximiser la lecture de fichiers ou à préparer une escalade. Le path traversal reste la technique fondamentale : en remontant l’arborescence avec des séquences ../, l’attaquant peut atteindre n’importe quel fichier accessible par le processus serveur, depuis le répertoire racine jusqu’aux répertoires système.

Les filtres côté serveur tentent souvent de bloquer ces séquences. Plusieurs techniques de contournement existent :

• Suppression naïve : si le serveur supprime simplement ../, injecter ….// ou …/./ — après suppression, la séquence ../ se reconstitue.
• URL encoding : %2e%2e%2f représente ../ et peut contourner des filtres qui ne décodent pas l’URL avant de filtrer.
• Double encoding : %252e%252e%252f est décodé une première fois en %2e%2e%2f par certaines couches, puis une seconde fois en ../ par l’interpréteur PHP.
• Null byte : historiquement, %00 en fin de chemin permettait de tronquer une extension ajoutée par le code (exemple : ../../../etc/passwd%00 pour supprimer le .php concaténé). Cette technique ne fonctionne plus sur les versions PHP récentes, mais reste pertinente sur des systèmes anciens non mis à jour.

Il est à noter que la directive PHP magic_quotes_gpc, lorsqu’elle était activée, échappait automatiquement les caractères spéciaux et limitait l’efficacité de la terminaison null. Cette directive est supprimée depuis PHP 5.4, ce qui rend ce point historique mais utile pour les audits de systèmes legacy.

Les stream wrappers offrent des vecteurs supplémentaires :

• php://filter : lecture encodée de fichiers PHP sans les interpréter.
• php://input : combiné à une requête POST, peut injecter du contenu arbitraire si allow_url_include est actif.
• data://text/plain;base64, : encode du code PHP en base64 et le fait interpréter directement.
• zip:// et phar:// : permettent d’inclure des fichiers depuis des archives, utiles si un upload de fichier est possible.

L’interprétation des réponses est aussi importante que l’injection. Une réponse vide peut signifier que le fichier existe mais est vide, que les permissions refusent la lecture, ou que le contenu est filtré en sortie. Une erreur 500 indique souvent une erreur d’interprétation PHP (le fichier inclus n’est pas du PHP valide). Une réponse avec du contenu binaire ou encodé suggère un wrapper actif. Chaque variation de réponse est une information à documenter.

Comprendre ce que l’on peut lire est la prochaine étape : certains fichiers ont un impact bien plus significatif que d’autres.

Mesurer l’impact : fichiers sensibles, secrets et exposition de données

L’impact d’une LFI dépend directement des fichiers accessibles via le compte système du serveur web. Sur un serveur Linux typique, le processus web tourne sous un utilisateur à privilèges limités (www-data, apache, nginx), mais les fichiers lisibles par cet utilisateur peuvent contenir des informations critiques.

Fichiers à fort impact sur Linux :

• /etc/passwd : liste des utilisateurs système, noms de compte, shells.
• /etc/hosts : cartographie réseau interne.
• /proc/self/environ : variables d’environnement du processus courant, souvent source de secrets (clés API, mots de passe de base de données).
• /proc/self/cmdline : ligne de commande du processus, révèle les arguments de démarrage.
• /var/log/apache2/access.log ou /var/log/nginx/access.log : logs d’accès, utiles pour le log poisoning (voir section suivante).
• Fichiers de configuration PHP : config.php, .env, wp-config.php, database.php — contiennent fréquemment des identifiants de base de données en clair.
• Clés SSH : /home/user/.ssh/id_rsa si les permissions le permettent.

Fichiers à fort impact sur Windows :

• C:Windowswin.ini : fichier de configuration système, utile pour confirmer la vulnérabilité.
• C:WindowsSystem32driversetchosts : équivalent de /etc/hosts.
• Fichiers de configuration IIS, web.config.

La criticité d’une LFI se mesure selon plusieurs axes :

L’exposition de données personnelles via une LFI peut également engager la responsabilité légale de l’organisation, notamment au regard du RGPD si des données d’utilisateurs sont stockées sur le serveur et lisibles via ce vecteur. La lecture du code source via php://filter est particulièrement dangereuse car elle ouvre la voie à la découverte de vulnérabilités supplémentaires dans l’application.

Lorsqu’une LFI permet d’accéder aux logs du serveur, le scénario d’escalade vers l’exécution de code devient concret.

De la lfi à l’exécution de code : scénarios et limites réelles

Une LFI seule permet de lire des fichiers. Pour franchir le cap de l’exécution de code arbitraire (RCE), des conditions supplémentaires doivent être réunies. Deux scénarios sont classiquement documentés : le log poisoning et le session poisoning.

Log poisoning : l’attaquant injecte du code PHP dans un fichier de log que le serveur web peut lire, puis force son inclusion via la LFI. La méthode consiste à envoyer une requête HTTP dont le User-Agent contient du code PHP (). Ce code est écrit dans le fichier de log d’accès. Ensuite, la LFI inclut ce fichier de log, et PHP interprète le code injecté. Les conditions nécessaires : le processus web doit pouvoir lire le fichier de log, et PHP doit interpréter le fichier inclus (ce qui est le cas avec include/require).

Session poisoning : PHP stocke les sessions dans des fichiers temporaires, généralement sous /tmp/sess_[SESSIONID] ou /var/lib/php/sessions/. Si l’application stocke une valeur contrôlée par l’utilisateur dans la session (via $_SESSION), et que cette valeur contient du code PHP, inclure le fichier de session via la LFI permet l’exécution. Le chemin du fichier de session est prévisible si l’identifiant de session est connu (cookie PHPSESSID).

D’autres vecteurs d’escalade existent :

• Upload + LFI : si l’application permet l’upload de fichiers (images, documents), un fichier contenant du code PHP peut être uploadé, puis inclus via la LFI. La validation du type MIME côté serveur peut être contournée.
• Wrappers data:// et php://input : si allow_url_include est activé, ces wrappers permettent l’injection directe de code sans passer par un fichier existant.
• SSRF via wrappers : dans certains contextes, une LFI peut être combinée avec des wrappers pour déclencher des requêtes internes, se rapprochant d’une SSRF (server-side request forgery).

Limites et faux positifs à cadrer :

• Si open_basedir est correctement configuré, la traversal est bloquée au niveau PHP avant même d’atteindre le système de fichiers.
• Un WAF peut filtrer les séquences ../ et les wrappers PHP dans les paramètres, rendant l’exploitation directe impossible sans contournement spécifique.
• Les logs peuvent être rotatifs ou écrits dans des chemins non accessibles par le processus web.
• Sur les distributions modernes, SELinux ou AppArmor peuvent bloquer l’accès à des fichiers sensibles même si PHP ne l’interdit pas.
• Un fichier de log très volumineux inclus via une LFI peut provoquer une saturation mémoire et un déni de service involontaire — raison supplémentaire de travailler en environnement de test.

La distance entre une LFI et une RCE est donc réelle mais franchissable dans des configurations courantes. C’est ce qui justifie de traiter toute LFI comme une vulnérabilité de sévérité élevée, même sans preuve immédiate d’exécution de code. Les correctifs à appliquer sont précis et non négociables.

Correction et durcissement : validations, allowlist et configuration serveur

La remédiation d’une LFI ne se limite pas à ajouter un filtre sur le paramètre vulnérable. Une approche en profondeur est nécessaire, car les filtres naïfs sont contournables. La stratégie optimale consiste à supprimer l’inclusion dynamique là où elle n’est pas strictement nécessaire, et à la contraindre drastiquement là où elle l’est.

1. Supprimer les inclusions dynamiques : dans la majorité des cas, le nombre de fichiers légitimement incluables est fini et connu à l’avance. Remplacer l’inclusion dynamique par un mapping statique est la solution la plus robuste :

Ce pattern d’allowlist avec mapping d’identifiants est recommandé par l’OWASP. L’entrée utilisateur ne construit jamais un chemin de fichier : elle sélectionne une clé dans un tableau contrôlé par le développeur.

2. Valider et canonicaliser les chemins : si une inclusion dynamique est inévitable, utiliser realpath() pour résoudre le chemin absolu réel, puis vérifier que ce chemin commence bien par le répertoire autorisé :

3. Durcissement de la configuration PHP :

• Définir open_basedir pour restreindre PHP au répertoire de l’application.
• Désactiver allow_url_include (désactivé par défaut, vérifier qu’il ne soit pas réactivé).
• Désactiver les stream wrappers risqués via disable_url_fopen_wrappers si non nécessaires.
• Activer display_errors = Off en production pour ne pas exposer les messages d’erreur PHP.
• Utiliser expose_php = Off pour masquer la version PHP dans les headers.

4. Permissions système : le processus web ne doit avoir accès en lecture qu’aux fichiers strictement nécessaires à l’application. Les fichiers de configuration contenant des secrets doivent être hors de la racine web (document root) et avec des permissions restrictives (600 ou 640).

5. Règles WAF : déployer des règles de filtrage sur les séquences ../, leurs encodages, et les préfixes de wrappers PHP (php://, data://, phar://). Les règles du Core Rule Set (CRS) de ModSecurity couvrent ces patterns. Un WAF ne remplace pas la correction dans le code, mais constitue une couche de défense supplémentaire.

Une fois les correctifs appliqués, la documentation et la vérification de leur efficacité sont indispensables.

Preuves, rapport et re-tests : documenter proprement et éviter la récidive

Un rapport de vulnérabilité LFI exploitable doit permettre à l’équipe de développement de reproduire le problème, de comprendre l’impact et d’appliquer le correctif sans ambiguïté. Un rapport incomplet ou mal structuré ralentit la remédiation et augmente le risque de récidive.

Structure minimale d’un rapport de LFI :

• Titre et identifiant : « LFI via paramètre page sur /index.php — Lecture de fichiers système ».
• Sévérité : score CVSS v3.1 calculé selon les vecteurs réels (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N pour une lecture de fichiers sensibles sans authentification).
• Étapes de reproduction : requête HTTP complète (méthode, URL, headers, body), réponse obtenue, outil utilisé. Suffisamment détaillé pour être rejoué par quelqu’un qui n’a pas participé au test.
• Preuve : capture d’écran ou extrait de réponse montrant le contenu du fichier sensible (anonymiser les données réelles si nécessaire en environnement de production).
• Impact : décrire concrètement ce qu’un attaquant peut faire avec cette vulnérabilité, pas seulement ce qu’elle est.
• Périmètre : préciser si d’autres endpoints similaires ont été testés et s’ils sont également vulnérables.
• Recommandations : correctifs spécifiques au contexte technique (langage, framework), pas des recommandations génériques.

Re-tests et non-régression : après application du correctif, un re-test doit valider que la vulnérabilité est effectivement corrigée et que le correctif n’a pas introduit de régression fonctionnelle. Tester non seulement le vecteur original, mais aussi les variantes d’encodage et les wrappers PHP pour s’assurer que la correction est complète.

Monitoring et détection continue : mettre en place des règles de détection dans les logs applicatifs et les outils SIEM pour alerter sur les patterns caractéristiques d’une tentative de LFI : séquences ../ dans les paramètres, préfixes php://, /etc/passwd, win.ini. Ces règles permettent de détecter des tentatives d’exploitation futures et de réagir rapidement.

Tests de non-régression automatisés : intégrer des tests de sécurité dans la pipeline CI/CD. Des outils d’analyse statique peuvent détecter les patterns d’inclusion dynamique non sécurisés dans le code source avant le déploiement. Couplés à des tests d’intégration incluant des vecteurs LFI connus, ils constituent un filet de sécurité contre la réintroduction de la vulnérabilité.

La documentation rigoureuse d’une LFI, de sa découverte à sa correction vérifiée, est ce qui transforme un audit ponctuel en amélioration durable de la posture de sécurité.

FAQ

Qu’est-ce qu’une local file inclusion (LFI) ?

Une LFI est une vulnérabilité qui force un serveur web à inclure un fichier présent localement sur son système de fichiers via un paramètre utilisateur non validé. Elle peut permettre la lecture de fichiers sensibles et, dans certaines conditions, l’exécution de code PHP arbitraire.

Quelle est la différence entre LFI et RFI ?

La LFI inclut un fichier local au serveur ; la RFI inclut un fichier distant, hébergé sur un serveur contrôlé par l’attaquant. La RFI nécessite que allow_url_include soit activé en PHP, ce qui est désactivé par défaut. La LFI est donc beaucoup plus fréquente dans les applications modernes.

Comment tester une LFI de manière sûre et légale ?

Uniquement dans un environnement de laboratoire dédié (DVWA, Docker, VM isolée) ou sur un périmètre explicitement autorisé par contrat. La méthode consiste à identifier les paramètres suspects, injecter des séquences de traversal progressives, capturer les preuves via un proxy, et ne jamais modifier de fichiers sur le système cible.

Une LFI permet-elle toujours d’exécuter du code ?

Non. Une LFI seule permet la lecture de fichiers. L’escalade vers l’exécution de code (RCE) nécessite des conditions supplémentaires : accès en lecture aux logs ou aux fichiers de session, possibilité d’y injecter du code PHP au préalable, ou activation de wrappers risqués. Ces conditions sont présentes sur des configurations non durcies mais pas universelles.

Comment corriger une LFI efficacement ?

La correction la plus robuste est la suppression de l’inclusion dynamique au profit d’un mapping statique (allowlist d’identifiants). Si l’inclusion dynamique est inévitable, canonicaliser le chemin avec realpath() et vérifier qu’il reste dans le répertoire autorisé. Compléter par le durcissement PHP (open_basedir, désactivation des wrappers risqués) et des règles WAF.

Une LFI non corrigée dans une application exposée sur internet constitue une porte d’entrée sérieuse : de la lecture de fichiers de configuration à l’exécution de code, le chemin existe et est documenté. La combinaison d’une validation stricte des entrées, d’une allowlist d’inclusions et d’un durcissement de la configuration PHP réduit cette surface à néant — sans complexité architecturale excessive.