Teil 1 – Was ist Local File Inclusion (LFI)?

Sep. 12, 2025

—

von

in Cyber Security, Local File Inclusion, Websecurity

Ein Einstieg mit einer Analogie

Stell dir vor, du bist in einer großen Bibliothek. Normalerweise gehst du zur Ausleihtheke und sagst dem Bibliothekar: „Bitte, ich hätte gerne das Buch Geschichte der Stadt.“ Der Bibliothekar schaut in einer Liste, greift ins richtige Regal und bringt dir das gewünschte Buch.

Jetzt stell dir aber vor, der Bibliothekar ist zu gutgläubig. Er bringt dir jedes Buch, das du nennst – selbst, wenn es eigentlich nur für Mitarbeiter gedacht ist. Sagst du: „Bitte das Buch Geheime Personalakten“, läuft er los und bringt es dir.

Genau so funktioniert Local File Inclusion (LFI) in Webanwendungen: Die Anwendung öffnet jede Datei, die du anforderst – auch Dateien, die eigentlich tabu sind.

Definition: Was ist LFI?

Local File Inclusion (LFI) ist eine Schwachstelle, bei der ein Angreifer Dateien vom Server laden kann, indem er Pfade in einer Webanwendung manipuliert.

„Local“ bedeutet: Die Dateien liegen auf dem gleichen Server wie die Webanwendung.
„File Inclusion“ heißt: Eine Datei wird in die Anwendung eingebunden oder angezeigt.

Das passiert meist, wenn eine Anwendung Eingaben von Nutzern (z. B. URL-Parameter) direkt in Funktionen wie include() oder file_get_contents() übergibt.

Ein einfaches Beispiel

Angenommen, eine Website lädt Inhalte so:

<?php
$page = $_GET["page"];
include($page . ".php");
?>

Die URL http://example.com/?page=about lädt die Datei about.php.

Angriff

Ein Angreifer ruft auf:

http://example.com/?page=../../etc/passwd

Die Anwendung versucht, die Datei /etc/passwd.php zu laden.
Wenn das .php weggelassen oder umgangen wird (z. B. mit Null-Byte-Inject %00 in alten PHP-Versionen), lädt die Anwendung die Datei /etc/passwd.

Das ist eine zentrale Konfigurationsdatei unter Linux, die alle Benutzer des Systems auflistet.

Warum das so gefährlich ist

Mit LFI kann ein Angreifer:

Systemdateien lesen: z. B. /etc/passwd, C:\Windows\win.ini.
Quellcode-Dateien lesen: z. B. config.php, .env mit Datenbankpasswörtern.
Logs auslesen: und evtl. manipulieren.
Kombinationsangriffe starten: z. B. durch „Log Poisoning“ oder mit einem zuvor hochgeladenen Script.

Directory Traversal – das Herzstück von LFI

Die meisten LFI-Angriffe nutzen Directory Traversal:

../ bedeutet „eine Ebene höher im Dateisystem“.
../../ zwei Ebenen höher.

Wenn die Anwendung im Verzeichnis /var/www/html/ läuft und man ../../etc/passwd angibt, landet man plötzlich im Ordner /etc/.

ASCII-Diagramm:

/var/www/html/
    ├── index.php
    ├── about.php
    └── contact.php
../../etc/passwd  →  /etc/passwd

Typische Angriffsziele

Linux/Unix-Systeme

/etc/passwd → Liste aller Benutzer
/etc/shadow → Passworthashes (nur mit root-Rechten lesbar, aber trotzdem gefährlich)
/proc/self/environ → Umgebungsvariablen, oft mit Pfaden oder Keys

Windows-Systeme

C:\Windows\win.ini → Standard-Konfiguration
C:\boot.ini → Boot-Einstellungen
C:\xampp\php\php.ini → PHP-Konfiguration

Web-Apps

config.php oder .env → Datenbank-Credentials
logs/access.log → Logs, die mit Benutzereingaben vergiftet werden können

Warum Entwickler LFI verursachen

Bequemlichkeit
Statt eine feste Liste von Templates zu laden, schreiben Entwickler: include($_GET["file"]); Das spart Zeit – aber öffnet Türen.
Fehlendes Input-Filtering
Viele glauben: „Unsere Nutzer geben doch nur about oder contact ein.“
Aber Angreifer geben ../../etc/passwd ein.
Legacy-Code
Alte PHP-Skripte, die nie aktualisiert wurden, sind besonders anfällig.

Analogie: Der Schlüssel zum ganzen Gebäude

LFI ist wie ein Schlüssel, der nicht nur eine Tür öffnet, sondern gleich das ganze Gebäude.

Normaler Nutzer: darf nur in den Ausstellungsraum.
Angreifer: trickst den Bibliothekar aus → plötzlich Zugang zu Archiv, Personalakten, Tresorraum.

Wie Angreifer kreativ werden

Ein reines LFI (Dateien lesen) ist schon gefährlich. Aber oft gehen Angreifer einen Schritt weiter:

Log Poisoning: Angreifer schreibt PHP-Code in ein Logfile (z. B. via User-Agent Header). Über LFI lädt er dieses Log → Code wird ausgeführt.
File Upload: Angreifer lädt eine „Bilddatei“ hoch, die eigentlich PHP enthält. Mit LFI bindet er die Datei ein → Remote Code Execution (RCE).
Chain Attacks: LFI + SQL-Injection oder LFI + XSS verstärken sich gegenseitig.

Wie man LFI erkennt

Oft tauchen in unsicheren URLs Parameter auf wie:

?page=about
?file=home
?template=main
?include=contact

Wenn man ../../etc/passwd einfügt und die App hängt sich auf oder gibt Systemdateien aus → LFI.

Kurzes Hands-On-Beispiel (gedanklich, nicht live testen)

http://example.com/?page=../../../../etc/passwd

Antwort:

root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
...

Das ist der Beweis für LFI.

Was du bis hier mitnehmen solltest

LFI = Local File Inclusion → Angreifer kann lokale Dateien des Servers einbinden/anzeigen.
Ursache: unkontrollierte Übergabe von Pfaden in include(), require(), file_get_contents() usw.
Technik: meist Directory Traversal (../).
Ziele: Systemdateien, Konfigurationsdateien, Logs, Quellcode.
Folgen: Informationslecks, Credential-Diebstahl, in Kombination sogar Remote Code Execution.