Was ist Remote File Inclusion?

Remote File Inclusion (RFI) entsteht, wenn eine Anwendung eine vom Angreifer gewählte externe Ressource als Code, Template oder Konfigurationsbestandteil lädt. Kann der Angreifer den entfernten Inhalt kontrollieren und wird er vom Server interpretiert, ist häufig direkte Codeausführung im Kontext der Anwendung möglich.

Wie funktioniert RFI?

Eine Anwendung verwendet beispielsweise einen Request-Parameter als Namen für ein Include. Akzeptiert die Laufzeit statt eines lokalen Namens auch https://attacker.example/payload oder einen Netzwerkpfad, holt der Server die Ressource und verarbeitet sie. RFI ist besonders aus älteren PHP-Anwendungen mit unsicherer URL-Include-Konfiguration bekannt. Das Grundproblem ist aber sprachunabhängig: Eine nicht vertrauenswürdige Partei bestimmt, welchen ausführbaren oder vertrauenswürdigen Inhalt der Server importiert.

Welche Voraussetzungen braucht ein Angriff?

• Die Dateiauswahl oder Importquelle ist durch Request-Daten beeinflussbar.
• Die verwendete Funktion und Laufzeit erlauben entfernte Schemes oder Netzwerkpfade.
• Der Anwendungsserver kann den entfernten Host über DNS und Netzwerk erreichen.
• Der geladene Inhalt wird in einem gefährlichen Kontext interpretiert statt nur als Daten behandelt.
• Positivlisten, Signaturprüfung oder andere Vertrauensprüfungen fehlen oder lassen sich umgehen.

Fehlt eine Voraussetzung, kann derselbe Parameter dennoch eine andere Schwachstelle verursachen – etwa Informationsleck, lokale Dateieinbindung oder serverseitigen Request.

Welche Folgen sind möglich?

Erfolgreiche RFI führt oft zu Remote Code Execution. Angreifer lesen Geheimnisse, manipulieren Daten, installieren Persistenz oder greifen weitere Systeme mit den Rechten des Anwendungsprozesses an. Wird der Inhalt zwar abgerufen, aber nicht ausgeführt, können interne Antworten, Cache-Manipulation oder Verfügbarkeitsprobleme entstehen. Egress-Filterung und geringe Prozessrechte begrenzen Folgen, ersetzen jedoch keine sichere Auswahl.

RFI, LFI oder SSRF?

Wie wird RFI verhindert?

1. Templates und ausführbare Module ausschließlich über feste interne Kennungen und eine serverseitige Positivliste wählen.
2. Remote Includes, URL-fähige Dateiwrapper und dynamisches Nachladen deaktivieren, wenn sie nicht zwingend benötigt werden.
3. Erforderliche Erweiterungen als signierte, versionierte Artefakte über einen kontrollierten Deployment-Prozess beziehen.
4. Ausgehenden Netzwerkzugriff des Dienstes auf notwendige Ziele beschränken und Redirects sowie DNS-Auflösung berücksichtigen.
5. Anwendung mit minimalen Rechten, schreibgeschütztem Code und getrennten Secrets betreiben.

Codebeispiel: Keine entfernten Include-Ziele zulassen

Verwundbar:

include $_GET['template'];

Sicherer:

$templates = [
    'invoice' => __DIR__ . '/templates/invoice.php',
    'receipt' => __DIR__ . '/templates/receipt.php',
];

$name = $_GET['template'] ?? '';
if (!isset($templates[$name])) {
    http_response_code(404);
    exit;
}

include $templates[$name];

In PHP sollten allow_url_include deaktiviert und ausgehende Netzwerkverbindungen des Webprozesses begrenzt sein. Diese Härtung ergänzt die feste Zuordnung, ersetzt sie aber nicht.

Wie wird RFI getestet?

Tester identifizieren dynamische Include-, Plugin-, Template- und Importparameter. Eine kontrollierte externe Ressource liefert einen eindeutigen harmlosen Marker; DNS- oder HTTP-Protokolle belegen, ob der Server sie abruft. Codeausführung wird nur mit ausdrücklicher Freigabe und einem nicht destruktiven Nachweis geprüft. Zusätzlich werden Schemes, Redirects, alternative Hostdarstellungen und lokale Pfade betrachtet, um RFI von SSRF und LFI abzugrenzen.