Penetrationstests für Webanwendungen: finden Sie die Lücken, bevor es ein anderer tut

Wir führen einen Webanwendungstest nach OWASP WSTG durch und prüfen nicht nur die klassischen Schwachstellen aus den OWASP Top 10 wie Injection, XSS oder Fehlkonfiguration, sondern vor allem die Geschäftslogik der Anwendung. Dort liegen die Fehler, die kein Scanner versteht, weil sie das Wissen erfordern, was die Anwendung tun soll.

Wir prüfen Authentifizierung und Sitzungsverwaltung, Zugriffskontrolle über Rollen und Konten hinweg, Dateiverarbeitung, API-Integrationen und die Stellen, an denen Nutzereingaben in die Datenbank, den Browser eines anderen Nutzers oder ein externes System gelangen. Jede Schwachstelle bestätigen wir mit einem funktionierenden Nachweis, nicht nur mit einem Tool-Alarm.

Die schwersten Vorfälle in Webanwendungen entstehen selten aus einer exotischen Lücke. Meist ist es Broken Access Control: ein Nutzer sieht die Daten eines anderen Kunden, tauscht eine Kennung in der URL und lädt fremde Rechnungen herunter, oder ein gewöhnliches Konto führt eine Aktion aus, die einem Administrator vorbehalten ist. OWASP setzt diese Kategorie seit Jahren an die Spitze seiner Risikoliste.

Ein Scanner findet diese nicht, denn ihre Bestätigung erfordert das Verständnis der Rollen und Berechtigungen in der Anwendung und den bewussten Versuch, sie zu umgehen. Deshalb testen wir aus der Perspektive verschiedener Konten und Rollen und prüfen jede Berechtigungsgrenze einzeln.

Wir richten das Testmodell nach dem Ziel. Im Black-Box-Ansatz bilden wir einen anonymen Angreifer aus dem Internet ab, was die Exposition gut zeigt, aber das auslässt, was nach dem Login passiert. Im Ansatz mit Testkonten, also Grey-Box, erreichen wir die Logik, die Nutzern zur Verfügung steht, und finden Autorisierungsfehler, die von außen unsichtbar sind.

Für eine Anwendung mit vielen Rollen und sensiblen Daten empfehlen wir meist Grey-Box, weil es das beste Verhältnis von Abdeckung zu Zeit bietet. Die Testkonten vereinbaren wir beim Scoping, damit der Test die realen Pfade Ihrer Nutzer abbildet.

Der Bericht enthält jede Schwachstelle mit Nachweis, CVSS-Bewertung und Reproduktionsschritten, damit Ihr Team das Problem bestätigen und sofort mit der Behebung beginnen kann. Dazu fügen wir eine Management-Zusammenfassung hinzu, die die reale geschäftliche Auswirkung ohne Fachjargon erklärt.

Nach der Umsetzung der Korrekturen führen wir einen Retest durch und bestätigen schriftlich, dass die Lücke geschlossen ist. So ist der Bericht nicht nur ein Dokument für die Schublade, sondern eine konkrete Maßnahmenliste mit bestätigter Wirkung, die Sie einem Kunden oder Auditor zeigen können.

Der beste Zeitpunkt ist kurz bevor die Anwendung in den Produktivbetrieb geht, sowie nach jeder wesentlichen Änderung: einer neuen Funktion, einer Integration, einer Änderung am Login oder einer Migration. Jede solche Änderung schafft eine neue Angriffsfläche, die ein früherer Test nicht abgedeckt hat.

Unabhängig von Änderungen empfehlen wir mindestens einen jährlichen Zyklus und einen häufigeren für Anwendungen, die personenbezogene Daten oder Zahlungen verarbeiten. Ein regelmäßiger Test ist auch eine ausdrückliche Anforderung mancher Regulierungen und häufiger Teil der Due Diligence bei Verträgen mit größeren Kunden.