Was ist Path Traversal?

Path Traversal, auch Directory Traversal genannt, entsteht, wenn nicht vertrauenswürdige Eingaben einen Dateisystempfad beeinflussen. Relative Bestandteile wie ../, absolute Pfade, alternative Trennzeichen oder kodierte Varianten können den endgültigen Pfad aus dem vorgesehenen Verzeichnis führen. Der Angreifer erreicht dadurch Dateien oder Verzeichnisse außerhalb des erlaubten Bereichs.

Wie funktioniert Path Traversal?

Eine Downloadfunktion bildet etwa /srv/reports/ plus den Parameter file. Mit einem Wert wie ../../config/app.env löst das Betriebssystem möglicherweise einen Pfad außerhalb von /srv/reports auf. Angriffsmuster variieren je nach Plattform, Framework und Anzahl der Dekodierungsschritte. URL-Encoding, doppelte Kodierung, Backslashes, Unicode-Normalisierung und symbolische Links können eine scheinbar einfache Filterung umgehen.

Wo tritt die Schwachstelle auf?

Welche Folgen sind möglich?

Lesezugriff kann Quellcode, Konfiguration, Zugangsdaten, private Schlüssel, Logs oder personenbezogene Daten offenlegen. Schreibzugriff ist oft kritischer: überschreibbare Konfiguration, Webdateien, SSH-Schlüssel oder geplante Aufgaben können Codeausführung und vollständige Übernahme ermöglichen. Bei Archivextraktion heißt die Variante häufig Zip Slip. Der Schaden wird durch die Dateirechte des Anwendungsprozesses begrenzt – ein Grund, Dienste nicht mit Administratorrechten auszuführen.

Was unterscheidet Path Traversal und File Inclusion?

Path Traversal beschreibt das Verlassen eines vorgesehenen Pfadbereichs beim Lesen oder Schreiben. Local File Inclusion beschreibt, dass die Anwendung eine ausgewählte lokale Datei als Code oder Template einbindet. LFI nutzt häufig Traversal, aber nicht jeder Traversal-Fehler führt zur Interpretation einer Datei. Eine reine Downloadfunktion kann vertrauliche Inhalte offenlegen, ohne sie auszuführen.

Wie wird Path Traversal verhindert?

1. Pfade vermeiden: Externe stabile IDs serverseitig auf bekannte Dateien abbilden.
2. Positivliste: Nur erwartete Namen, Typen und bei Bedarf Erweiterungen erlauben.
3. Kanonisieren: Den endgültigen Pfad einmal auflösen und sicher prüfen, dass er innerhalb des erwarteten Basisverzeichnisses liegt.
4. Race Conditions beachten: Prüfung und Zugriff so verbinden, dass Symlinks oder Änderungen dazwischen die Grenze nicht umgehen.
5. Rechte begrenzen: Separates Dienstkonto, restriktive Mounts und schreibgeschütztes Dateisystem einsetzen.
6. Uploads sicher benennen: Servergenerierte Namen und sichere Archivbibliotheken verwenden.

Das Entfernen von ../ reicht nicht: verschachtelte Sequenzen können nach der Ersetzung wieder entstehen, und spätere Dekodierung verändert die Eingabe. Entscheidend ist der kanonische Zielpfad direkt vor dem Zugriff.

Codebeispiel: Dateipfade nicht vom Client übernehmen

Verwundbar:

$name = $request->input('file');
return response()->download(
    storage_path('app/exports/' . $name)
);

Sicherer Entwurf mit indirekter Referenz:

$export = $request->user()
    ->exports()
    ->whereKey($request->route('export'))
    ->firstOrFail();

return Storage::disk('private')->download(
    $export->storage_key,
    $export->original_name
);

Der Client wählt nur eine Objekt-ID. Speicherpfad und Downloadname stammen aus getrennten serverseitigen Feldern; die Beziehung prüft zugleich die Berechtigung.

Wie wird es getestet?

Tester identifizieren alle dateibezogenen Parameter und prüfen relative, absolute, kodierte und plattformspezifische Pfade. Lesende Nachweise verwenden eine harmlose bekannte Datei; Schreibtests benötigen einen eigens vereinbarten Zielbereich und eine sichere Bereinigung. Fehlermeldungen, unterschiedliche Antwortlängen und Zeitverhalten liefern Hinweise, müssen aber durch einen kontrollierten Nachweis bestätigt werden. Auch Archive, Symlinks und alternative API-Versionen gehören in die Prüfung.