Was ist Local File Inclusion?

Local File Inclusion (LFI) entsteht, wenn eine Anwendung eine vom Benutzer beeinflussbare lokale Datei als Code, Template oder Seitenbestandteil einbindet. Häufig soll ein Parameter nur eine Sprache oder Ansicht auswählen, wird aber direkt an eine Include- oder Template-Funktion übergeben. Der Angreifer kann dann andere Dateien des Servers auswählen.

Wie entsteht LFI?

Eine Anwendung lädt beispielsweise sinngemäß include("pages/" + page + ".php"). Ohne feste Zuordnung kann eine manipulierte Eingabe den vorgesehenen Ordner verlassen oder auf eine andere lokale Ressource zeigen. Automatisch ergänzte Erweiterungen, Dekodierung, Nullbyte-Probleme älterer Laufzeiten und plattformspezifische Pfade beeinflussen, welche Dateien erreichbar sind. Moderne Frameworks reduzieren klassische Muster, eigene Loader, Altanwendungen und dynamische Template-Auswahl bleiben jedoch relevant.

Welche Auswirkungen hat LFI?

Welche Dateien lesbar sind, bestimmen Betriebssystemrechte, Container- oder Chroot-Grenzen und der Anwendungsprozess. Geringe Rechte begrenzen den Schaden, beheben den Include-Fehler aber nicht.

Wann wird daraus Codeausführung?

LFI führt nicht automatisch zu Remote Code Execution. Dafür muss der Angreifer meist kontrollierbare Inhalte in eine Datei bringen, die anschließend als ausführbarer Code interpretiert wird. Historische Angriffsketten nutzten manipulierte Logzeilen, Session-Dateien, temporäre Uploads oder andere beschreibbare Ressourcen. Ob das funktioniert, hängt von Interpreter, Dateiformat, Pfadkenntnis, Schreibmöglichkeit und Konfiguration ab. Auch ohne Codeausführung kann der reine Dateizugriff kritisch sein.

LFI, Path Traversal oder RFI?

Wie wird LFI verhindert?

1. Externe Werte wie de oder invoice über eine feste serverseitige Map auf bekannte Templates abbilden.
2. Keine vollständigen Pfade, Wrapper oder URLs aus Request-Daten an Include-Funktionen übergeben.
3. Anwendungscode, Uploads, Logs, Sessions und temporäre Dateien in getrennten Bereichen mit passenden Rechten speichern.
4. Nicht benötigte Interpreter-Wrapper und Remote-Includes deaktivieren; Produktionsfehler ohne interne Pfade ausgeben.
5. Wenn Dateiauswahl unvermeidbar ist, kanonischen Pfad und Positivliste unmittelbar vor Zugriff prüfen.

Codebeispiel: Templates über feste Bezeichner auswählen

Verwundbar:

include __DIR__ . '/pages/' . $_GET['page'] . '.php';

Sicherer:

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

$page = $_GET['page'] ?? 'help';
if (!array_key_exists($page, $pages)) {
    http_response_code(404);
    exit;
}

include $pages[$page];

Ein bereinigter Dateiname ist schwächer als diese Zuordnung: Er lässt oft unerwartete Dateien innerhalb eines Verzeichnisses zu. Wenn lediglich Text ausgeliefert werden soll, darf er außerdem nicht mit include als PHP interpretiert werden.

Wie wird LFI getestet?

Tester erfassen Parameter für Sprache, Template, Download, Theme und Vorschau und prüfen, ob unerwartete lokale Dateien geladen werden. Ein minimaler Nachweis verwendet eine harmlose, bekannte Datei und vermeidet das Auslesen produktiver Geheimnisse. Danach werden mögliche Schreibquellen und die Art der Interpretation bewertet, ohne ungefragt Code auszuführen. Unterschiedliche Fehler, Antwortinhalte und Serverlogs helfen bei der Bestätigung.