Path Traversal (Directory Traversal)

Path Traversal, auch Directory Traversal genannt, ist eine klassische, aber nach wie vor häufige Web-Schwachstelle: Mit einer Handvoll Zeichen bricht ein Angreifer aus dem Verzeichnis aus, in dem Ihre Anwendung ihn halten wollte, und liest Dateien an anderer Stelle auf dem Server. Dieser Beitrag erklärt, was Path Traversal ist, wie ein solcher Angriff abläuft, was ein Angreifer damit erreichen kann und wie Sie Ihre Anwendung dagegen absichern.

Was ist Path Traversal?

Path Traversal (auch Directory Traversal) ist eine Schwachstelle, bei der ein Angreifer einen Dateinamen oder Pfad aus Benutzereingaben so manipuliert, dass die Anwendung Dateien außerhalb des vorgesehenen Verzeichnisses öffnet. Der Schlüssel ist die Zeichenfolge ../, die auf nahezu jedem Betriebssystem “ein Verzeichnis nach oben” bedeutet. Indem er diese Folge oft genug wiederholt, klettert der Angreifer bis zum Wurzelverzeichnis des Dateisystems und steigt von dort zu genau der Datei hinab, die er sucht.

Stellen Sie sich einen Archivmitarbeiter vor, der Dokumente anhand einer Wegbeschreibung heraussucht, die der Besucher ausfüllt. Vorgesehen ist, dass er nur im öffentlichen Schrank kramt. Das Formular verlangt aber wörtlich einen Pfad, und der Besucher schreibt: “Verlassen Sie den öffentlichen Schrank, eine Etage höher, in den Personalschrank, holen Sie die Gehaltsakte.” Der Mitarbeiter befolgt die Anweisung brav, denn sie ist ja ordentlich eingetragen. Die Zeichenfolge ../ ist genau diese Anweisung “eine Etage höher”, und die Anwendung führt sie bedenkenlos aus.

Wie funktioniert ein Path-Traversal-Angriff?

Path Traversal taucht überall dort auf, wo eine Anwendung einen vom Benutzer gelieferten Namen mit einem Pfad auf dem Server verbindet und das Ergebnis öffnet: bei einer Download-Funktion, einem Template-Loader, einer Sprachdatei oder einem “Logdatei ansehen”-Bildschirm. Solange diese Eingabe nicht geprüft wird, bestimmt der Benutzer, welcher Pfad entsteht.

Verwundbar:

// Download-Funktion, die den angegebenen Dateinamen direkt an einen Basispfad hängt
app.get('/download', (req, res) => {
  const file = req.query.file;
  const filePath = path.join('/var/www/files', file);
  res.sendFile(filePath);
});

Im Normalfall ruft jemand /download?file=handbuch.pdf auf und erhält sauber /var/www/files/handbuch.pdf zurück. Doch path.join rechnet ../ einfach aus. Ruft ein Angreifer /download?file=../../../../etc/passwd auf, verdunstet der Basispfad während dieser Berechnung, und der Server liefert /etc/passwd aus, die Liste der Systembenutzer. Unter Windows funktioniert dasselbe mit dem Backslash, über eine Anfrage wie ..\..\..\windows\win.ini oder eine Konfigurationsdatei voller Passwörter. Die Anzahl der ../ muss nicht genau stimmen: Weiter nach oben als bis zum Wurzelverzeichnis geht es nicht, denn dieses bildet die Obergrenze, weshalb ein Angreifer ruhig ein paar zu viele stapelt, um sicher in der Root zu landen.

Sicher:

import path from 'node:path';

const BASE_DIR = path.resolve('/var/www/files');

app.get('/download', (req, res) => {
  const requested = req.query.file ?? '';

  // Den Pfad vollständig auflösen und prüfen, ob er im Basisverzeichnis bleibt
  const resolved = path.resolve(BASE_DIR, requested);
  if (resolved !== BASE_DIR && !resolved.startsWith(BASE_DIR + path.sep)) {
    return res.status(403).send('Zugriff verweigert');
  }

  res.sendFile(resolved);
});

Die sichere Variante vertraut nicht auf die Eingabe, sondern auf das Endergebnis. Zuerst wird der vollständige Pfad mit path.resolve aufgelöst, sodass jeder ../-Sprung tatsächlich ausgerechnet wird. Danach prüft der Code, ob dieser aufgelöste Pfad noch immer innerhalb von BASE_DIR liegt. Zeigt er außerhalb des Basisverzeichnisses (egal, wie viele ../ der Angreifer stapelt) wird die Anfrage abgewiesen. Diese nachträgliche Prüfung ist zuverlässiger als der Versuch, ../ aus der Eingabe zu filtern, denn solches Filtern lässt sich mit Doppelkodierung, Backslashes oder exotischen Varianten immer wieder umgehen.

Welche Auswirkungen hat Path Traversal?

Was ein Path Traversal wert ist, hängt davon ab, was auf dem Server liegt, das erklärt die Spanne von medium bis hoch. Im günstigsten Fall liest ein Angreifer nur Dateien, die wenig preisgeben. Meist liegt jedoch mehr in Reichweite: Quellcode, Konfigurationsdateien mit Datenbank-Passwörtern, eine .env voller API-Schlüssel, private SSH-Schlüssel oder Sitzungsdateien, mit denen sich Konten übernehmen lassen.

Technisch reicht der Schaden über das reine Lesen hinaus. Kann der Angreifer über dieselbe Lücke auch Dateien schreiben oder überschreiben (etwa über eine Upload- oder Entpackfunktion, die Pfade nicht prüft, das sogenannte Zip Slip) so schreibt er eine Web-Shell weg oder ersetzt vorhandenen Code und wertet Path Traversal damit zu Remote Code Execution auf. Für das Unternehmen bedeutet das mindestens ein Datenleck und im schlimmsten Fall einen vollständig kompromittierten Server. Weil die Lücke kein besonderes Werkzeug erfordert und oft mit einer einzigen HTTP-Anfrage ausnutzbar ist, wird sie von automatisierten Angreifern in großem Umfang abgetastet.

Wie spürt man Path Traversal auf?

Bei einem manuellen Test gibt ein Pentester in jedes Feld, das einen Dateinamen, Pfad, eine Sprache oder ein Template zu verarbeiten scheint, Varianten von ../ ein und achtet darauf, was zurückkommt. Liefert ../../../../etc/passwd den Inhalt dieser Datei, oder verrät eine Fehlermeldung einen absoluten Pfad, dann ist es ein Treffer. Zudem werden Kodierungstricks erprobt (URL-Kodierung, Doppelkodierung, Backslashes unter Windows) um schwache Filter zu entlarven. Parameter, die verdächtig nach Dateiverweisen aussehen, etwa file=, path=, template= oder lang=, erhalten besondere Aufmerksamkeit. Automatische Scanner finden die offensichtlichen Fälle, übersehen aber häufig die Stellen, an denen Eingaben indirekt in einen Pfad gelangen. AssistSec berücksichtigt Path Traversal standardmäßig in einem Penetrationstest und prüft gezielt diese weniger sichtbaren Eingabepunkte.

Wie verhindert man Path Traversal?

• Lösen Sie den vollständigen Pfad auf und prüfen Sie, dass er innerhalb des erlaubten Basisverzeichnisses bleibt; weisen Sie alles andere ab.
• Setzen Sie nach Möglichkeit auf eine Allowlist oder einen indirekten Verweis (etwa eine ID, die Sie einem festen Dateinamen zuordnen) statt auf einen frei eingebbaren Pfad.
• Entfernen Sie Verzeichnisanteile mit path.basename, wenn der Benutzer nur einen einzelnen Dateinamen angeben muss.
• Dekodieren Sie Eingaben vollständig vor der Validierung, damit %2e%2e%2f und Doppelkodierung keinen Filter umgehen können.
• Verlassen Sie sich nicht auf das Herausfiltern von ../; validieren Sie stets den endgültigen, aufgelösten Pfad.
• Betreiben Sie die Anwendung mit minimalen Rechten, damit der Prozess bei Missbrauch möglichst wenige Dateien lesen kann.
• Bewahren Sie sensible Dateien wie .env, Schlüssel und Backups außerhalb jedes Verzeichnisses auf, das der Webserver erreichen kann.