Directory Traversal: Der unterschätzte Albtraum in Websecurity

Stell dir vor, jemand klingelt an deiner Haustür, und du lässt ihn in den Flur. Alles gut soweit – aber plötzlich schleicht er durch alle Zimmer, kramt in deinen Schubladen und liest sogar deine privaten Dokumente. Genau das passiert digital, wenn eine Webanwendung gegen Directory Traversal nicht abgesichert ist.

Bei diesem Angriff nutzen Hacker einfache Tricks wie ../, um sich außerhalb des vorgesehenen Verzeichnisses zu bewegen und so Zugriff auf vertrauliche Dateien zu bekommen – vom unscheinbaren Logfile bis hin zu geheimen Konfigurationsdateien. Klingt simpel? Ist es auch. Und genau deshalb ist diese Schwachstelle brandgefährlich.

In diesem Artikel schauen wir uns an, wie Directory Traversal funktioniert, welche Beispiele es in der Praxis gibt, warum diese Sicherheitslücke oft unterschätzt wird – und wie du deine Anwendungen so absicherst, dass kein Angreifer durch deine „digitalen Schubladen“ stöbern kann.

Was ist Directory Traversal?

Directory Traversal ist eine Sicherheitslücke, bei der ein Angreifer über manipulierte Pfadangaben Dateien und Verzeichnisse außerhalb des eigentlich vorgesehenen Bereichs eines Webservers (oder eines Dateisystems) zugänglich machen kann. Oft sieht das so aus, dass jemand in einer URL oder in Parametern ../ (oder ..\ unter Windows) benutzt, um sich „nach oben“ im Verzeichnisbaum zu hangeln – also aus dem “Web-Root” oder einem geschützten Verzeichnis herauszuklettern, um an sensible Dateien zu gelangen.

Ein paar Synonyme und verwandte Begriffe:

Path Traversal
File Path Traversal
Directory Climbing / Backtracking
CWE-22 (Common Weakness Enumeration für Improper Limitation of a Pathname to a Restricted Directory)

Warum ist das gefährlich?

Weil solche Lücken oft zu richtig fiesen Konsequenzen führen:

Lesen von vertraulichen Dateien, z. B. /etc/passwd, Konfigurationsdateien, private Schlüssel, Logdateien, etc.
In manchen Fällen sogar Schreiben oder Modifizieren (z. B. bei Archiv-Extraktion, Symbolischen Links, etc.)
Mögliches Remote Code Execution, wenn ein Angreifer durch das Lesen/Modifizieren von Dateien die Kontrolle übernehmen kann.
Datenverlust, Imageverlust, rechtliche Probleme (Datenschutzverletzungen), und natürlich Vertrauensverlust.

Typen & Varianten

Bevor wir in Beispiele gehen: Hier sind ein paar wichtige Varianten von Directory Traversal:

Variante	Beschreibung
Relative Path Traversal	Nutzung von ../ oder ..\ von einem bestehenden Pfad aus, um nach oben zu navigieren.
Absolute Path Traversal	Angabe eines vollständigen Pfades wie /etc/passwd oder C:\Windows\system32\drivers\etc\hosts.
Encodierte / URL-Encoded Traversal	Pfade oder die ../-Sequenz werden URL-kodiert, z. B. %2e%2e%2f etc., um einfache Filter zu umgehen.
Unicode / Nicht-Standard Kodierung	Verschleierung durch Unicodeausdrücke oder Mehrfachkodierungen, um Filter zu tricksen.
Archiv- / ZIP-Traversal	Wenn man Archivdateien entpackt, die referenzierte Verzeichnisse außerhalb erlaubter Bereiche enthalten (z. B. durch symbolische Links oder Pfadangaben in der ZIP).

Richtig gefährliche Beispiele aus der Praxis

Damit das nicht theoretisch bleibt – hier sind ein paar reale Fälle:

Der WordPress-Plugin “SEO Tools” war anfällig dafür, dass über einen file-Parameter relative Pfade genutzt wurden, um z. B. Windows-Systemdateien wie win.ini auszulesen.
Der Rank Math SEO-Plugin hatte kürzlich eine Path Traversal Schwachstelle: CVE-2023-23888.
Der Squirrly SEO-Plugin (Version < 6.1.5) hatte eine Directory Traversal Schwachstelle via Parameter sq_size.

Diese Beispiele zeigen: Selbst große, weithin genutzte Plugins sind nicht immun. Und oft ist das Problem schlicht zu wenig Eingabevalidierung oder zu lockere Datei-Pfad-Verarbeitung.

Wie erkennt man Directory Traversal?

Als Sicherheits-Profi oder Entwickler solltest du folgende Anzeichen im Code / in Requests prüfen:

Parameter, die direkt in Datei-Operationen verwendet werden (z. B. include(...), open(...), readfile(...)) ohne vorherige Validierung oder „whitelisting“.
„../“, „..\“, doppelte Kodierung (%2e, %2f, etc.), Unicode-Umwege in Parametern.
Fehlende oder zu schwache Beschränkungen, dass Pfade immer unter einem bestimmten Basisverzeichnis bleiben.
Fehlermeldungen oder Stack Traces, die Rückschlüsse auf das Dateisystem erlauben.
Zugriff auf Dateien, die nicht öffentlich sein sollten (z. B. .env, config.php, etc.).
Logdateien, die ungewöhnliche Pfade oder mehrfaches „../“ zeigen.

Directory Traversal finden — Schritt für Schritt

Hinweis: Führe diese Schritte nur in einer autorisierten Testumgebung oder mit schriftlicher Erlaubnis durch. Die Beispiele nutzen eine harmlose Testdatei lab-proof.txt, die du im Webroot anlegst.

1) Vorbereitung (Lab)

Lege in deiner Testwebapp im Verzeichnis uploads/ die Datei lab-proof.txt mit dem Inhalt lab-test-2025 an.
Aktiviere Server-AccessLogs und ErrorLogs.
Stelle sicher, dass der Webserver anderswo (z. B. /etc/) sensible Dateien enthält, diese aber nicht gelesen werden — wir werden sie nicht anfragen.
Starte einen Proxy (z. B. Burp, ZAP) zum Mitschneiden der Requests.

Beispiel (nur Beschreibung):
/var/www/html/uploads/lab-proof.txt -> Inhalt: lab-test-2025

Tipp: Es gibt bereits fertige Labs, die du verwenden kannst, um deine Fähigkeiten zu trainieren z. B. Hack the Box (HTB)

2) Recon - Endpunkte & Parameter finden

Suche in der Webapp nach Hinweisen, welche URLs/Parameter Dateinamen akzeptieren. Typische Kandidaten: download, file, img, path, document, view.

Beispiel-URL (gefunden in einer Seite oder API-Beschreibung):
https://test.local/download?file=...

Notiere den Request-Typ (GET/POST), Parametername und Content-Type.

Kontrollierten Zugriff prüfen

Ziel: Beweise, dass der Parameter tatsächlich Dateien liefert – mit der kontrollierten Testdatei.

Beispiel Request (GET)

GET /download?file=uploads/lab-proof.txt HTTP/1.1
Host: test.local
User-Agent: curl/8.2.1
Accept: */*

Equivalent mit curl:

curl -i "https://test.local/download?file=uploads/lab-proof.txt"

Beispiel Response - erfolgreicher Zugriff

HTTP/1.1 200 OK
Content-Type: text/plain
Content-Length: 13
Server: TestServer/1.0
lab-test-2025

Interpretation:

Status 200 OK + Body enthält lab-test-2025 → der file-Parameter steuert Dateizugriff.

Wenn du dieses Verhalten siehst, hast du eine sichere, reproduzierbare Basis für weitere Tests.

3) Varianten testen — konzeptionell & nicht destruktiv

Jetzt systematisch Variationen durchlaufen, um Hinweise auf Traversal-Anfälligkeit zu bekommen. Wichtig: Hier nur harmlose Pfadvariationen verwenden (z. B. zum selben lab-proof.txt).

Ziel: Prüfen, ob die Applikation Pfadmanipulationen zulässt.

Beispiel 1 — relative Pfad-Variante (konzeptionell)

GET /download?file=uploads/../uploads/lab-proof.txt HTTP/1.1
Host: test.local

Mögliche Response (wenn Normalisierung fehlt)

HTTP/1.1 200 OK
Content-Length: 13
lab-test-2025

Bedeutung: Die Applikation hat die ..-Sequenz nicht ausreichend normalisiert oder geprüft — sie folgt dem Pfad und liest trotzdem die Datei.

4) Systematische Hypothesentests (strukturierter Ansatz)

Arbeite mit klaren Hypothesen und dokumentiere Ergebnisse.

Beispiel-Hypothese:
file wird ungefiltert an readFile() weitergegeben, ohne Canonicalization.“

Testschritte:

Baseline: /download?file=uploads/lab-proof.txt → 200 + lab-test-2025 (erfolg).
Variation A: /download?file=uploads/../uploads/lab-proof.txt → 200? Wenn ja, Hypothese gestützt.
Variation B: URL-kodierte Form der Variation → Verhalten prüfen.
Logs prüfen: Wird ../ im Log auftauchen? Welche Error-Messages?

Protokolliere: Request, Response (Status, Headers, Body-Snippet), Log-Zeilen, Zeitstempel.

5) Proof-of-Concept (PoC) — sicher & minimal

Dein PoC sollte zeigen, dass die Lücke vorhanden ist, ohne produktive Dateien zu lesen.

Beispiel PoC (gefüllter Report-Abschnitt)

Endpunkt: GET /download?file=...
Parameter: file
Testdatei: uploads/lab-proof.txt (Inhalt: lab-test-2025)
Reproduktionsschritte (konzeptionell):
1. Lege lab-proof.txt in uploads/ an.
2. Request: GET /download?file=uploads/lab-proof.txt → 200 + lab-test-2025.
3. Request: GET /download?file=uploads/../uploads/lab-proof.txt → ebenfalls 200 + lab-test-2025.
Beleg: Kopien der beiden Responses (Status + Body-Auszug) + passende Logzeile.
Risikoeinschätzung: Mittlere bis hohe Auswirkung — ein Angreifer könnte möglicherweise Pfadmanipulation nutzen, um außerhalb vorgesehener Bereiche zu lesen. (Keine Tests gegen produktive Dateien durchgeführt.)

6) Empfehlungen für sichere Tests / No-Go-Regeln

Nicht an produktiven Systemen ohne explizite Genehmigung testen.
Keine Versuche, sensible oder Systemdateien zu lesen.
Keine Schreib-/Lösch-Operationen durchführen.
Begrenze Request-Raten, um Systeme nicht zu überlasten.
Dokumentiere jeden Schritt, sodass du später nachvollziehbar berichten kannst.

Schutzmaßnahmen / Gegenmaßnahmen

Hier kommen meine Top-Tipps, wie man Directory Traversal verhindert – aus mehreren Jahrzehnten Erfahrung:

Eingabevalidierung & Whitelisting
Canonicalization (Pfadnormalisierung)
Vermeide die direkte Weitergabe von Benutzerinput in Dateisystem-APIs
Restriktive Dateisystemrechte
Logging & Monitoring
Aktualisierung & Patches
Testen / Penetration Tests / Code Reviews

Codebeispiele

Damit alles etwas greifbarer wird, hier zwei einfache Codebeispiele – eines unsicher, eines sicher.

Beispiel unsicher (PHP)

# Pseudocode – verwundbare Version (keine Bereinigung)
wenn url_parameter("file") vorhanden:
    pfad = url_parameter("file")
    datei_laden("/var/www/html/uploads/" + pfad)  # ← kein Schutz!

Wenn jemand ?file=../../etc/passwd benutzt, wird möglicherweise die Datei /etc/passwd inkludiert.

Beispiel sicher

# Pseudocode – sichere Version mit Whitelist-Prüfung
wenn url_parameter("file") vorhanden:
    dateiname = basis_name(url_parameter("file"))  # entfernt "../" etc.
    erlaubt = ["image1.jpg", "image2.png", "report.pdf"]
    wenn dateiname in erlaubt:
        datei_laden("/var/www/html/uploads/" + dateiname)
    sonst:
        fehler_senden(400, "Ungültige Datei.")

Plus: Statt include könnte man realpath() oder canonicalize() Funktionen nutzen, um zu prüfen, ob der Pfad innerhalb des erlaubten Verzeichnisses bleibt.

Weitere Tools & Ressourcen

CWE-22 – als Referenz für diese Art von Schwachstelle.
Sicherheitsscanner wie OWASP ZAP, Burp Suite, Acunetix – die haben Regeln für Path / Directory Traversal.
CVE-Datenbanken, Patch-Listen vieler Plugins (z. B. WordPress Plugins wie Rank Math, Squirrly) als Beispiele, was aktuell angreifbar war.

Häufige Fehler & Bypasses

Erfahrung lehrt: Selbst mit guten Maßnahmen kann man in Fallen tappen. Hier sind typische Fehler und Bypass-Techniken:

Wildcards oder Pfadangaben, die nicht ausreichend gefiltert werden.
Mehrfache Kodierung (z. B. %2e%2e%2f, Unicode-Kodierungen) umgehen einfache Filter.
Null-Byte-Injection (früher ein häufiger Trick) – je nach Sprache/Plattform relevant.
Symbolische Links innerhalb erlaubter Verzeichnisse, die auf außerhalb gehen.
Fehlerhafte Konfiguration der Basisverzeichnisse oder root paths.
Logikfehler: Man prüft den Pfad vor dem Konkatenieren, aber nach Kodierung / Normalisierung nicht erneut.

Fazit

Directory Traversal mag auf den ersten Blick wie ein „einfacher Trick“ wirken — ein paar .. und schon ist die Welt offen. In Wahrheit ist das Problem viel tiefer: Es ist ein Architektur- und Design-Fehler kombiniert mit zu wenig Input-Hygiene und laxen Rechten. Die größten Risiken entstehen, wenn Entwickler Dateipfade direkt aus Nutzerinput bauen, und Administratoren Dateisysteme so konfigurieren, dass sensible Dateien unnötig zugänglich sind.

Was du mitnehmen solltest: Vermeide Blacklists, setze auf Whitelists und Canonicalization, betreibe restriktives Rechtemanagement, und überwache anomalieverdächtige Pfadzugriffe. Für Betreiber heißt das: Patchen, prüfen, logs auswerten. Für Entwickler heißt das: niemals blind Dateien aus Nutzerinput öffnen — stattdessen Referenzen, IDs oder ein striktes Mapping benutzen.

Und für alle: Übe regelmäßig im Lab, führe Penetrationstests kontrolliert durch und handle immer rechtlich und ethisch korrekt. Directory Traversal ist eine Low-Tech-Lücke mit High-Impact — ignoriere sie nicht.