Directory Traversal (auch Path Traversal genannt) ist eine Sicherheitslücke in Webanwendungen, bei der ein Angreifer Zugriff auf Dateien oder Verzeichnisse außerhalb des beabsichtigten Verzeichnisses erhält. Dabei nutzt der Angreifer manipulierte Pfadangaben, um sich durch das Dateisystem des Servers zu bewegen.

Wie funktioniert ein Directory Traversal Angriff?

Eine unsichere Webanwendung verarbeitet Dateipfade oft direkt aus Benutzereingaben, z. B. in einer URL wie:

https://example.com/getFile?file=report.pdf

Wenn der Server die Eingabe nicht ausreichend überprüft, könnte ein Angreifer sie manipulieren:

https://example.com/getFile?file=../../../../etc/passwd

Hierbei nutzt der Angreifer ../ (die Parent-Directory-Notation), um sich aus dem vorgesehenen Verzeichnis herauszubewegen und eine Systemdatei wie /etc/passwd (unter Linux) auszulesen.

Gefahren eines erfolgreichen Angriffs

• Auslesen sensibler Daten (Konfigurationsdateien, Quellcode, Benutzerlisten)
• Kompromittierung des Servers (wenn z. B. SSH-Keys oder Passwort-Hashes gestohlen werden)
• Ausführung von Schadcode, falls die Datei modifiziert oder ausgeführt werden kann

Schutzmaßnahmen

• Eingabevalidierung: Nutzerinput filtern und nur erlaubte Zeichen zulassen
• Verwendung sicherer Pfade: Keine direkte Verwendung von Benutzereingaben für Dateioperationen
• Least Privilege Prinzip: Webserver sollten nur minimale Rechte für den Zugriff auf Dateien haben
• Whitelisting von Dateipfaden: Nur bekannte und erlaubte Dateien abrufen lassen

CORS (Cross-Origin Resource Sharing) ist ein Sicherheitsmechanismus, der von Webbrowsern implementiert wird, um zu kontrollieren, welche Webseiten auf Ressourcen von anderen Domains zugreifen dürfen. Standardmäßig blockieren Browser aus Sicherheitsgründen sogenannte Cross-Origin-Anfragen, also Anfragen von einer Webseite an eine andere Domain, ein anderes Protokoll oder einen anderen Port.

Warum gibt es CORS?

Ohne CORS könnten bösartige Webseiten im Hintergrund Anfragen an andere Server senden (z. B. API-Server oder Banking-Seiten), wodurch sensible Daten gestohlen oder missbraucht werden könnten (Cross-Site Request Forgery, CSRF). CORS sorgt dafür, dass nur explizit erlaubte Webseiten auf Ressourcen zugreifen dürfen.

Wie funktioniert CORS?

Wenn eine Webanwendung eine Cross-Origin-Anfrage stellt (z. B. von http://example.com an https://api.example.com), sendet der Browser automatisch eine CORS-Anfrage. Der Server kann dann in den HTTP-Headern antworten, ob die Anfrage erlaubt ist:

1. Ohne CORS-Header:
   Der Browser blockiert die Anfrage.

2. Mit CORS-Headern:
   Der Server kann mit Access-Control-Allow-Origin: * (alle Domains) oder einer bestimmten Domain (Access-Control-Allow-Origin: https://example.com) antworten. Damit wird der Zugriff erlaubt.

Preflight-Requests

Für einige Anfragen (z. B. mit PUT, DELETE, speziellen Headern) führt der Browser einen Preflight-Request mit der OPTIONS-Methode aus. Der Server muss dann mit den richtigen CORS-Headern antworten, um die Hauptanfrage zu ermöglichen.

Fazit

CORS ist eine wichtige Sicherheitsmaßnahme, die verhindert, dass unerlaubte Webseiten auf fremde Ressourcen zugreifen. Entwickler müssen serverseitig die richtigen Header setzen, um den Zugriff für legitime Clients zu erlauben.

Remote Code Execution (RCE) ist eine schwerwiegende Sicherheitslücke, bei der ein Angreifer in der Lage ist, bösartigen Code auf einem entfernten Computer oder Server auszuführen. Dies kann passieren, wenn ein System Schwachstellen in der Software hat, die es einem Angreifer ermöglichen, beliebigen Code einzuschleusen und auszuführen. RCE-Angriffe können schwerwiegende Folgen haben, da sie dem Angreifer die Kontrolle über das betroffene System geben können.

Wie funktioniert Remote Code Execution?

RCE tritt auf, wenn ein Angreifer Schwachstellen in einer Anwendung, einem Betriebssystem oder einer Netzwerkkomponente ausnutzt, um Code in das System einzuschleusen und auszuführen. Solche Schwachstellen können sich in verschiedenen Teilen einer Anwendung befinden, wie z.B.:

1. Webanwendungen: Unsichere Eingabevalidierung, SQL-Injection, unsichere Deserialisierung, oder andere Schwachstellen in Webanwendungen können zu RCE führen.
2. Server-Software: Schwachstellen in Webservern, Datenbankservern oder anderen Serveranwendungen können ausgenutzt werden.
3. Netzwerkdienste: Dienste, die über das Netzwerk erreichbar sind und Schwachstellen aufweisen, können Ziel von RCE-Angriffen sein.

Beispiel eines RCE-Angriffs:

Ein häufiges Beispiel ist eine unsichere Webanwendung, die Benutzereingaben nicht richtig validiert. Wenn ein Angreifer bösartigen Code in ein Eingabefeld eingibt und die Anwendung diese Eingabe ohne ausreichende Überprüfung verarbeitet, kann der Code auf dem Server ausgeführt werden.

# Ein einfaches Beispiel in Python
import os

def execute_command(user_input):
    os.system(user_input)

# Angreifer gibt ein: "ls; rm -rf /"
execute_command("ls; rm -rf /")

Mögliche Auswirkungen von RCE:

• Komplettübernahme des Systems: Der Angreifer kann volle Kontrolle über das betroffene System erlangen.
• Datenverlust oder -diebstahl: Sensible Daten können gestohlen oder gelöscht werden.
• Weiterverbreitung von Malware: Der Angreifer kann Malware installieren und verbreiten.
• Ausspähen und Ausnutzen weiterer Systeme: Der kompromittierte Server kann als Ausgangspunkt für Angriffe auf andere Systeme im Netzwerk verwendet werden.

Schutzmaßnahmen gegen RCE:

1. Eingabevalidierung: Alle Benutzereingaben sollten gründlich validiert und gefiltert werden.
2. Aktualisierungen und Patches: Regelmäßige Updates und Patches für alle Softwarekomponenten sollten durchgeführt werden, um bekannte Schwachstellen zu schließen.
3. Least Privilege Principle: Anwendungen sollten nur die minimal notwendigen Berechtigungen haben, um ihre Aufgaben auszuführen.
4. Verwendung sicherer Kodierungspraktiken: Sichere Programmiertechniken und -bibliotheken sollten verwendet werden, um Schwachstellen zu vermeiden.
5. Intrusion Detection Systems (IDS): Systeme zur Erkennung und Abwehr von Eindringlingen sollten implementiert werden, um verdächtige Aktivitäten zu erkennen und zu verhindern.

Durch die Implementierung dieser Maßnahmen kann das Risiko eines RCE-Angriffs erheblich reduziert werden.

Server Side Includes (SSI) Injection ist eine Sicherheitslücke, die in Webanwendungen auftritt, die Server Side Includes (SSI) verwenden. SSI ist eine Technik, die es ermöglicht, HTML-Dateien serverseitig dynamisch zu generieren, indem spezielle Befehle in HTML-Kommentaren eingebettet werden. Diese Befehle werden vom Webserver interpretiert und ausgeführt, bevor die Seite an den Client ausgeliefert wird.

Wie funktioniert SSI Injection?

Bei einer SSI Injection greift ein Angreifer die Webanwendung an, indem er bösartige SSI-Befehle in Eingabefelder, URLs oder andere Mechanismen einschleust, über die die Anwendung Daten vom Benutzer akzeptiert. Wenn die Anwendung diese Eingaben nicht richtig überprüft und filtert, können die eingeschleusten Befehle auf dem Server ausgeführt werden.

Beispiel eines SSI-Befehls:

Dieser Befehl würde auf einem anfälligen Server den Inhalt des aktuellen Verzeichnisses auflisten.

Mögliche Auswirkungen einer SSI Injection:

• Dateisystemmanipulation: Angreifer können Dateien lesen, ändern oder löschen.
• Remote Code Execution: Ausführung beliebiger Befehle auf dem Server, was zu einer vollständigen Kompromittierung führen kann.
• Informationsdiebstahl: Zugriff auf sensible Daten, wie Konfigurationsdateien oder Datenbankinhalte.
• Dienstunterbrechung: Durchführen von Befehlen, die den Server zum Absturz bringen oder überlasten.

Schutzmaßnahmen gegen SSI Injection:

1. Eingaben validieren und filtern: Alle Benutzereingaben sollten gründlich überprüft und auf zulässige Werte beschränkt werden.
2. Verwendung von Prepared Statements: Wo möglich, sollte man vorbereitete Anweisungen und parameterisierte Abfragen verwenden, um die Möglichkeit von Injektionen zu minimieren.
3. Beschränkung der Nutzung von SSI: Wenn möglich, sollte die Verwendung von SSI ganz vermieden werden, insbesondere wenn es keine zwingende Notwendigkeit dafür gibt.
4. Sicherheitsmechanismen des Servers nutzen: Konfigurieren Sie den Webserver so, dass er nur vertrauenswürdige SSI-Befehle akzeptiert und führt keine gefährlichen Shell-Befehle aus.

Indem diese Maßnahmen ergriffen werden, kann das Risiko einer SSI Injection erheblich reduziert werden.