Ein Web Application Penetration Test (WAPT) ist eine kontrollierte Simulation eines realen Angriffs auf eine Webanwendung. Das Ziel besteht darin, Schwachstellen – sowohl offensichtliche als auch versteckte – zu identifizieren, bevor sie von einem Angreifer ausgenutzt werden können. Dieser Leitfaden beschreibt die operativen Phasen eines WAPT, die am häufigsten verwendeten Tools sowie zu vermeidende Fehler, mit einem praktischen Fokus für IT-Profis und Sicherheitsverantwortliche.

1. Konfiguration der Testumgebung

Bevor mit den Aktivitäten begonnen wird, muss eine isolierte und kontrollierte Umgebung eingerichtet werden. Die grundlegenden Komponenten sind:

• Kali Linux: Die Referenz-Distribution für Penetrationstests mit einer breiten Palette vorinstallierter Tools, darunter Schwachstellen-Scanner, Traffic-Analysatoren und Exploit-Frameworks.
• Virtuelle Maschine: Isoliert die Testumgebung vom Host-Betriebssystem und begrenzt mögliche Nebenwirkungen der durchgeführten Aktivitäten.
• Burp Suite: Ein unverzichtbares Tool zum Abfangen und Manipulieren von HTTP-Anfragen. Als Proxy konfiguriert, ermöglicht es die Analyse des Datenverkehrs zwischen Browser und Webanwendung sowie die Identifizierung von Schwachstellen im Kommunikationsfluss.

2. Informationsbeschaffung

Eine sorgfältige Informationsbeschaffung ist die Grundlage für jeden effektiven Test. Sie gliedert sich in zwei Hauptaktivitäten:

• Footprinting: Sammlung öffentlich verfügbarer Informationen über das Ziel, einschließlich eventueller Datenlecks, die von Suchmaschinen indexiert wurden, sowie die Kartierung der Einstiegspunkte der Anwendung.
• Enumeration: Identifizierung der auf dem Server vorhandenen Anwendungen, Fingerprinting des verwendeten Frameworks und Rekonstruktion der Architektur, um bekannte Schwachstellen in Verbindung mit den erkannten Technologien zu finden.

3. Bewertung der Schwachstellen

In dieser Phase werden automatisierte Tools und manuelle Analysen kombiniert, um eine vollständige Abbildung der vorhandenen Schwachstellen zu erhalten:

• Nmap: Port-Scanning und Identifizierung aktiver Dienste auf dem Ziel, nützlich zur Entdeckung ungeschützter Angriffsflächen.
• OWASP ZAP: Automatischer Scanner für häufige Schwachstellen in Webanwendungen, wie SQL-Injection und Cross-Site Scripting (XSS).
• Nikto: Ein spezifischer Scanner für Webserver, der auf die Identifizierung von Fehlkonfigurationen und bekannten Schwachstellen auf Infrastrukturebene ausgerichtet ist.

4. Exploitation

Die Exploitation-Phase prüft, ob die identifizierten Schwachstellen tatsächlich ausnutzbar sind. Die häufigsten Typen in Webanwendungen sind:

• SQL-Injection: Ermöglicht die Ausführung nicht autorisierter SQL-Befehle. SQLmap automatisiert die Erkennung und Ausnutzung dieser Schwachstellen, einschließlich Blind SQL-Injection.
• Command Injection: Erlaubt die Ausführung beliebiger Befehle auf dem Server. Die Identifizierung erfordert gezielte manuelle Testtechniken.
• Cross-Site Scripting (XSS): Ermöglicht das Einschleusen schädlicher Skripte in Webseiten. Burp Suite unterstützt die Identifizierung von reflektierten und gespeicherten Varianten.
• Directory Traversal: Ermöglicht den unbefugten Zugriff auf Dateien auf dem Server. Tools wie DotDotPwn automatisieren diese Art von Angriff.
• Insecure Direct Object References (IDOR): Schwachstellen, die den Zugriff auf nicht autorisierte Ressourcen durch Manipulation von Anfrageparametern ermöglichen.

---

Praxisbeispiel an einer Demo-Anwendung

Verwundbare Anwendungen wie OWASP WebGoat oder Damn Vulnerable Web App (DVWA) bieten eine sichere Umgebung zum Üben. Ein typisches Beispiel ist die Ausnutzung einer SQL-Injection-Schwachstelle mittels SQLmap: Das Tool identifiziert den anfälligen Parameter, extrahiert die Datenbankstruktur und ruft Daten ab, was die Auswirkungen der Schwachstelle konkret demonstriert.

---

5. Analyse der Geschäftslogik

Schwachstellen in der Geschäftslogik gehören zu den am schwierigsten mit automatisierten Tools zu erkennenden Fehlern. Sie betreffen Mängel im vorgesehenen Anwendungsablauf: zum Beispiel die Möglichkeit, obligatorische Schritte in einem Kaufprozess zu überspringen, Preise clientseitig zu ändern oder ohne die erforderlichen Berechtigungen auf geschützte Funktionen zuzugreifen. Diese Phase erfordert ein Verständnis des Anwendungskontexts und kann nicht vollständig an Scanner delegiert werden.

6. Post-Exploitation

Sobald eine Schwachstelle ausgenutzt wurde, bewertet die Post-Exploitation-Phase die tatsächlichen Auswirkungen für das Unternehmen:

• Privilegieneskalation: Überprüfung, ob es möglich ist, ausgehend von einem eingeschränkten Erstzugriff Administratorrechte im System zu erlangen.
• Datenexfiltration: Identifizierung, welche sensiblen Daten zugänglich wären und über welche Pfade, einschließlich möglicher Methoden zur Umgehung bestehender Sicherheitskontrollen.

Häufige Fehler, die vermieden werden sollten

• Überspringen der Informationsbeschaffung: Eine unzureichende Voranalyse reduziert die Qualität des Tests erheblich.
• Sich nur auf automatische Scanner verlassen: Automatisierte Tools erkennen keine logischen oder kontextuellen Schwachstellen; manuelle Tests sind unerlässlich.
• Vernachlässigung der Geschäftslogik: Einige der kritischsten Schwachstellen ergeben sich nicht aus technischen Scans.
• Tests in der Produktion durchführen: Tests in Produktionsumgebungen können Dienstunterbrechungen verursachen und Auswirkungen auf echte Daten haben.
• Ergebnisse nicht dokumentieren: Ohne einen strukturierten Bericht besteht die Gefahr, dass die identifizierten Schwachstellen nicht systematisch behoben werden.

Häufig gestellte Fragen

• Was ist der Unterschied zwischen einem Vulnerability Assessment und einem Web Application Penetration Test?
• Das Vulnerability Assessment identifiziert und katalogisiert vorhandene Schwachstellen, ohne deren tatsächliche Ausnutzbarkeit zu prüfen. Der WAPT geht weiter: Er simuliert einen realen Angriff, um zu verifizieren, ob die Schwachstellen konkret ausnutzbar sind und welche Auswirkungen sie auf die Anwendung und die Daten hätten.
• Wie oft sollte ein WAPT durchgeführt werden?
• Im Allgemeinen mindestens einmal jährlich und immer dann, wenn wesentliche Änderungen an der Anwendung vorgenommen werden. Für kritische Anwendungen oder solche, die sensible Daten verarbeiten, wird eine häufigere Frequenz empfohlen.
• Erfordert ein WAPT Zugriff auf den Quellcode?
• Nicht unbedingt. Ein Black-Box-Test wird ohne Zugriff auf den Code durchgeführt und simuliert einen externen Angreifer. Ein White-Box-Test beinhaltet die Analyse des Quellcodes und liefert tiefergehende Ergebnisse. Die Wahl hängt von den Zielen und dem Kontext des Tests ab.
• Welche Vorschriften erfordern oder empfehlen Penetrationstests für Webanwendungen?
• PCI DSS erfordert explizit regelmäßige Penetrationstests für Systeme, die Zahlungsdaten verarbeiten. NIS2 und ISO/IEC 27001 empfehlen Sicherheitsüberprüfungen, einschließlich Penetrationstests, als Teil eines strukturierten Risikomanagementprogramms.
• Was muss der Abschlussbericht eines WAPT enthalten?
• Ein effektiver Bericht enthält eine Zusammenfassung für das Management (Executive Summary), die technische Beschreibung jeder Schwachstelle mit entsprechender Schweregradklassifizierung (z. B. CVSS), den Nachweis der Ausnutzbarkeit und priorisierte Empfehlungen zur Behebung (Remediation).

Nützliche weiterführende Informationen

Wenn Sie überlegen, wie Sie die Sicherheit Ihrer Anwendungen oder der gesamten Infrastruktur strukturieren sollen, können Ihnen diese Dienste helfen, den passenden Weg zu definieren:

• Web Application Penetration Testing — der WAPT-Service von ISGroup: manuelle Angriffssimulation auf Webanwendungen nach OSSTMM- und OWASP-Methodik.
• Vorbereitung und Planung eines WAPT — wie man Scope, Berechtigungen, Testumgebung und Remediation vor der Durchführung festlegt.
• OWASP Top Ten in der Praxis — Beispiele für Anwendungsschwachstellen, die während eines Web-Penetrationstests geprüft werden sollten.
• Vulnerability Assessment — nicht-invasive Aktivitäten zur Identifizierung bekannter Schwachstellen in Infrastrukturen und Anwendungen, nützlich als Ausgangspunkt oder als wiederkehrende Aktivität.
• Code Review — White-Box-Analyse des Quellcodes zur Identifizierung von Schwachstellen, die bei dynamischen Tests nicht zum Vorschein kommen.
• Vulnerability Management Service — kontinuierliches Schwachstellenmanagement mit regelmäßigen Scans, Berichten und operativer Unterstützung bei der Behebung.