Wie strukturieren Sie einen Webanwendungstest mit dem OWASP WSTG?
Kurzantwort
Der WSTG ist eine checklistengestützte Methodik, die eine App durch Testkategorien führt: Informationsbeschaffung, Konfiguration und Deployment, Identität und Authentifizierung, Autorisierung, Session-Management, Eingabevalidierung (Injection/XSS), Fehlerbehandlung, Kryptografie, Geschäftslogik und Client-seitig. Er bietet systematische Abdeckung mit stabilen Test-IDs, sodass Befunde reproduzierbar sind und nichts Offensichtliches übersprungen wird.
Der OWASP Web Security Testing Guide (WSTG) verwandelt „teste die Web-App" in einen systematischen, wiederholbaren Prozess. Interviewer greifen darauf zurück, weil ein erfahrener Tester nicht zufällig an URLs herumstochert — er arbeitet ein strukturiertes Set von Kategorien ab, sodass die Abdeckung nachweisbar ist und Befunde stabile Kennungen tragen, die andere reproduzieren können.
Die Testkategorien
Der WSTG ordnet das Testen in eine logische Abfolge:
- Informationsbeschaffung. Server, Frameworks und Einstiegspunkte fingerprinten und die Angriffsfläche der Anwendung kartieren.
- Konfigurations- und Deployment-Management. TLS, HTTP-Header, Standarddateien, Admin-Oberflächen, Cloud- und Infrastruktur-Fehlkonfigurationen.
- Identität und Authentifizierung. Kontenaufzählung, schwache Passwortrichtlinien, MFA-Bypass, Fehler bei der Passwortwiederherstellung.
- Autorisierung. Privilegieneskalation, Insecure Direct Object References (IDOR), Path Traversal — erzwingt die App, wer was tun darf?
- Session-Management. Token-Stärke, Fixation, Logout, Cookie-Attribute.
- Eingabevalidierung. Die klassische Injection-Familie — SQLi, XSS, SSRF, Command Injection.
- Fehlerbehandlung und Kryptografie. Informationslecks, schwache Chiffren, unsachgemäße Schlüsselbehandlung.
- Geschäftslogik. Missbrauch legitimer Funktionen — die Fehler, die Scanner nicht finden können.
- Client-seitig. DOM XSS, CORS, postMessage und JavaScript-Probleme, die im Browser leben.
Warum die Struktur zählt
Die Kategorien erzwingen Abdeckung: Ein Scanner findet reflektiertes XSS, versteht aber nie, dass „den Bezahlschritt überspringen und trotzdem die Ware erhalten" der eigentliche Bug ist. Die stabilen Test-IDs (z. B. WSTG-ATHZ) erlauben es Ihnen, Befunde zu mappen, den Fortschritt zu verfolgen und einem Remediation-Team etwas Reproduzierbares zu übergeben.
Worauf Interviewer achten
Sie wollen sehen, dass Sie Automatisierung mit manueller Tiefe verbinden — DAST nutzen, um Breite abzudecken, und dann menschliche Zeit für Autorisierung und Geschäftslogik aufwenden, die Kategorien, die wirklich einen denkenden Angreifer erfordern.
Wahrscheinliche Anschlussfragen
- Wie testen Sie Geschäftslogik-Fehler, die Scanner nicht finden können?
- Was ist der Unterschied zwischen Authentifizierungs- und Autorisierungstests im WSTG?
- Wie würden Sie den WSTG mit automatisiertem DAST kombinieren, ohne in False Positives zu ertrinken?