Aller au contenu principal
Expert Cybersécurité & IAv9.0
Centres de ressources conformité
Besoin d'un accompagnement expert ?
Devis personnalisé sous 24h — audit, conformité, incident
Checklists Sécurité — Audit & Durcissement
Formats disponibles
📄 PDF 📊 Excel 🌐 Web

11 checklists professionnelles couvrant 2 200+ points de contrôle. Téléchargement gratuit, aucune inscription.

Local File Inclusion (LFI)

hacking

Définition

La Local File Inclusion (LFI) est une vulnérabilité web qui permet à un attaquant d'inclure des fichiers locaux présents sur le serveur dans la réponse HTTP d'une application. Elle survient quand une application inclut dynamiquement des fichiers selon un paramètre fourni par l'utilisateur sans validation ou assainissement suffisant. La LFI est classée dans les vulnérabilités d'injection de chemins (Path Injection) et figure dans l'OWASP Top 10. Le vecteur typique est un paramètre de type ?page=about ou ?fichier=rapport.php où la valeur est directement utilisée dans une instruction d'inclusion de fichier côté serveur (PHP include(), require(), Python open(), etc.). En injectant des séquences de traversée de répertoire (../../../etc/passwd), l'attaquant peut référencer n'importe quel fichier accessible par le processus web. Les cibles classiques d'une LFI sur Linux incluent : /etc/passwd (liste des utilisateurs), /etc/shadow (hachages de mots de passe, si les permissions le permettent), /proc/self/environ (variables d'environnement du processus, souvent avec des headers HTTP), /var/log/apache2/access.log (log d'accès Apache), et des fichiers de configuration spécifiques à l'application. Sur Windows : C:\Windows\System32\drivers\etc\hosts, les fichiers de configuration IIS, les journaux d'événements. Une technique puissante combinent LFI et empoisonnement de logs (Log Poisoning) : l'attaquant injecte du code PHP dans un champ enregistré dans les logs (User-Agent, Referer) comme <?php system($_GET['cmd']); ?>, puis inclut le fichier de log via LFI. Cela transforme une LFI en RCE (Remote Code Execution). D'autres variantes utilisent /proc/self/fd, les sessions PHP (/tmp/sess_XXXXX), et les wrappers PHP (php://filter, php://input, data://). La LFI avec les wrappers PHP est particulièrement puissante : php://filter/convert.base64-encode/resource=config.php retourne le code source PHP encodé en base64, révélant les credentials de base de données, les clés d'API, et la logique applicative sans déclencher l'exécution du PHP.

Fonctionnement

Exemple PHP vulnérable : include($_GET['page'] . '.php');. Payload de traversée : ?page=../../../../etc/passwd%00 (null byte pour tronquer l'extension .php en PHP < 5.3). Payload wrapper : ?page=php://filter/convert.base64-encode/resource=config retourne config.php encodé en base64. Payload RCE via log poisoning : 1) envoyer une requête avec User-Agent contenant <?php system($_GET['c']); ?>, 2) inclure /var/log/apache2/access.log via LFI + passer &c=id.

Exploitation offensive

La LFI est souvent le premier pied dans une application web menant à la RCE. Les tests LFI sont systématiques dans tout pentest web : fuzzer les paramètres d'inclusion avec des listes de chemins (SecLists LFI wordlists), tester les wrappers PHP, et vérifier la traversée de répertoire avec différents encodages (URL encoding, double encoding, unicode). Des outils comme LFISuite et wfuzz automatisent la détection.

Détection et mitigation

Les WAF (Web Application Firewall) détectent les séquences ../ et les chemins absolus dans les paramètres. La mitigation fondamentale est de ne jamais utiliser des entrées utilisateur directement dans des fonctions d'inclusion : utiliser une liste blanche de fichiers autorisés, un tableau de correspondance (switch/case), ou valider strictement contre un regex limitant les caractères autorisés (alphanumérique uniquement). chroot/jail pour le processus web limite l'accès au système de fichiers.

Articles liés

Un projet cybersécurité ?

Expert dispo · Réponse 24h

Devis