Web Penetration Testing · Moritz Samrock

Web Penetration Testing ist die methodische, autorisierte Sicherheitsprüfung von Webanwendungen, Single-Page-Apps, APIs und deren zugrunde liegender Infrastruktur. Ziel ist es, ausnutzbare Schwachstellen zu finden, bevor echte Angreifer sie entdecken. Ein Web Pentest geht weit über automatisierte Scans hinaus: Erfahrene Tester prüfen Authentifizierungsabläufe, Autorisierungslogik, Session-Handling, Eingabevalidierung und geschäftsspezifische Workflows, die kein Scanner abbilden kann.

Wer beauftragt diesen Test?

Typische Auftraggeber sind CISOs, Product Owner, Entwicklungsleiter und Compliance-Verantwortliche. Organisationen, die PCI-DSS-Konformität (Requirement 6), SOC 2 Type II oder eine ISO-27001-Zertifizierung anstreben, benötigen Web Pentests häufig als Nachweis der Sorgfaltspflicht. Auch Produktteams beauftragen sie vor dem Launch einer kundenorientierten Anwendung oder nach einer grundlegenden Architekturänderung.

Ziel des Tests

Das Ziel ist die Identifikation möglichst vieler ausnutzbarer Schwachstellen innerhalb des definierten Scopes, die Bewertung ihrer realen Auswirkungen und die Bereitstellung konkreter Behebungsempfehlungen. Anders als bei einem Vulnerability Assessment wird die Ausnutzbarkeit durch kontrollierte Exploitation nachgewiesen, nicht nur potenziell vorhandene Probleme gemeldet.

Was wird getestet?

Geprüft wird die gesamte Angriffsfläche einer Webanwendung: Authentifizierung und Session-Management, rollen- und attributbasierte Zugriffskontrolle, Eingabeverarbeitung über alle Parameter, Datei-Upload-Funktionalität, API-Endpunkte, WebSocket-Kanäle, clientseitige Logik, Drittanbieter-Integrationen, Serverkonfiguration und HTTP-Security-Header. Die Geschäftslogik wird manuell geprüft, da automatisierte Tools anwendungsspezifische Workflows nicht verstehen können.

Übliche Schwachstellen und Findings

Typische Schwachstellen sind Cross-Site Scripting (Reflected, Stored und DOM-basiert), SQL Injection, Insecure Direct Object References (IDOR), fehlerhafte Zugriffskontrolle mit horizontaler und vertikaler Rechteeskalation, Cross-Site Request Forgery, Server-Side Request Forgery, Sicherheitsfehlkonfigurationen wie exponierte Adminpanels oder ausführliche Fehlermeldungen, unsichere Datei-Uploads mit der Möglichkeit zur Remote Code Execution, fehlerhafte Authentifizierungsmechanismen, JWT-Implementierungsfehler, Session Fixation, Informationsabfluss über HTTP-Header und Stacktraces sowie fehlende Security-Header wie Content Security Policy und HSTS. Die Testmethodik orientiert sich typischerweise an den OWASP Top 10 und dem OWASP ASVS.

Ablauf eines Web Penetrationstests

Ein Web Penetrationstest folgt einem strukturierten Prozess von der Erstanfrage bis zum Projektabschluss.

Interesse und Erstanfrage — der Kunde nimmt Kontakt auf, beschreibt die zu testende Anwendung und den geschäftlichen Anlass (Compliance, Pre-Launch, wiederkehrende Prüfung).

Erstgespräch zum Verständnis der Kundenziele — Tester und Kunde besprechen die Anwendungsarchitektur, den Technologie-Stack, die Anzahl der Rollen, authentifiziertes vs. nicht-authentifiziertes Testen und etwaige Ausschlussbereiche. Daraus entsteht die Aufwandsschätzung.

Angebotserstellung und Freigabe — ein formales Angebot wird erstellt mit Scope, Methodik, Zeitplan, Deliverables und Preisgestaltung. Der Kunde prüft und gibt frei.

Scope-Definition — die genauen Ziele werden dokumentiert: URLs, Umgebungen (Staging vs. Produktion), Testkonten pro Rolle, API-Dokumentation und etwaige Einschränkungen.

Letter of Engagement — ein rechtlich bindendes Dokument autorisiert den Test, regelt Haftung, Notfallkontakte und Kommunikationswege. Es schützt beide Seiten.

Erstellung weiterer Freigaben — wird die Anwendung bei einem Drittanbieter oder in der Cloud gehostet, kann eine schriftliche Genehmigung des Hosters erforderlich sein. WAF-Whitelisting oder IP-Freischaltung wird arrangiert.

Bereitstellung von Informationen je nach Black-/Gray-/White-Box-Ansatz — je nach gewähltem Ansatz stellt der Kunde Zugangsdaten, API-Dokumentation, Quellcode-Zugang oder Architekturdiagramme bereit.

Kick-Off Call — Tester, Entwickler und Stakeholder stimmen Logistik, Eskalationswege, Testfenster und Kommunikationsrhythmus ab.

Durchführung mit laufender Information der Stakeholder — die Tester arbeiten die Anwendung methodisch durch und informieren bei kritischen Findings sofort, statt auf den Abschlussbericht zu warten. Tägliche oder periodische Statusupdates sorgen für Transparenz.

Sammlung und Bewertung der Schwachstellen — alle Findings werden mit Reproduktionsschritten, Nachweisen (Screenshots, HTTP-Requests/-Responses) und einer Schweregradbewertung dokumentiert (typischerweise CVSS oder ein risikobasiertes Modell aus Eintrittswahrscheinlichkeit und Auswirkung).

Erstellung des Abschlussberichts — ein umfassender Bericht enthält eine Management Summary, detaillierte technische Findings, Risikobewertungen und spezifische Behebungsempfehlungen für jede Schwachstelle.

Vorstellung in einer Präsentation — die Ergebnisse werden sowohl dem technischen als auch dem Management-Publikum vorgestellt, mit Erklärung der Findings, ihrer geschäftlichen Auswirkungen und priorisierter Behebungsschritte.

Projektabschluss — das Engagement wird formal abgeschlossen. Ein Retest wird typischerweise vereinbart, nachdem der Kunde die Findings adressiert hat.

Wer sollte diesen Test wann durchführen lassen?

Jede Organisation, die Webanwendungen betreibt, sollte Web Penetrationstests beauftragen. Typische Anlässe sind der Launch neuer Anwendungen, größere Releases oder Architekturänderungen, ein jährlicher Baseline-Test sowie Compliance-Anforderungen (PCI DSS quartalsweise/jährlich, SOC 2, ISO 27001). Organisationen, die sensible Daten verarbeiten — Finanzdienstleister, Gesundheitswesen, E-Commerce — sollten häufiger testen und nach jeder wesentlichen Codeänderung.