Web Application Pentest

Was ein Web Application Pentest abdeckt

Ein Web Application Pentest ist die systematische Sicherheitsprüfung einer Webanwendung in einem klar definierten Scope. Das Ziel: möglichst viele Schwachstellen finden, ihre Ausnutzbarkeit verifizieren und sie so dokumentieren, dass dein Team sie effizient beheben kann. Wie sich Pentesting von anderen Assessment-Formen unterscheidet, zeigt unser Überblick über Penetration Testing im DACH-Raum.

Der entscheidende Punkt ist das Wort manuell. Automatisierte Tools setzen wir gezielt ein, sie ergänzen aber nur und ersetzen nie die manuelle Analyse. Ein Scanner erkennt bekannte Schwachstellen anhand von Mustern. Er versteht jedoch nicht, was deine Anwendung tut: welche Rolle welche Daten sehen darf, welche Abläufe sich gegen ihre Geschäftsregeln ausnutzen lassen und welche Funktionen wirklich kritisch sind. Genau dort liegen die Schwachstellen mit dem größten Schadenspotenzial, und genau dort setzen wir an.

Jede Prüfung wird individuell auf deine Anwendung zugeschnitten, mit oder ohne Authentifizierung, je nach Anforderung und Schutzbedarf.

Was wir testen

Den genauen Prüfumfang stimmen wir im Scoping auf deine Anwendung ab. Die Kernbereiche sind bei jedem Web Application Pentest dieselben:

• OWASP Top 10 und darüber hinaus: die bekanntesten Schwachstellenklassen als Basis, ergänzt um Angriffe, die in keiner Checkliste stehen.
• Authentifizierung & Session-Management: Login, Registrierung, Passwort-Reset, Session-Handling und Rechteverwaltung, die kritischen Funktionen jeder Anwendung.
• Autorisierung & IDOR: Zugriffskontrolle über Rollen und Objekte hinweg. Kann Benutzer A die Daten von Benutzer B lesen oder verändern? Kommt ein normaler Benutzer an Admin-Funktionen?
• Business-Logik: Fehler im Anwendungsfluss, die sich gegen die Geschäftsregeln der Anwendung ausnutzen lassen. Diese Klasse findet kein automatisiertes Tool, weil sie fachliches Verständnis der Anwendung voraussetzt.
• APIs (REST & GraphQL): Schnittstellen und Datenflüsse, von Authentifizierung und Autorisierung bis zu Injection und übermäßiger Datenpreisgabe.
• Injection-Klassen: SQL-Injection, Cross-Site-Scripting (XSS), Command Injection und verwandte Angriffe auf jede Stelle, an der deine Anwendung Eingaben verarbeitet.

Wann ein Web Application Pentest sinnvoll ist

Die typischen Anlässe für eine Prüfung:

• Vor dem Go-live: eine neue Anwendung oder ein Relaunch geht online, und du willst wissen, was ein Angreifer findet, bevor er es selbst herausfindet.
• Nach größeren Änderungen: neue Authentifizierung, neue API, neues Rollenmodell. Jede Änderung an kritischen Funktionen kann neue Schwachstellen einführen.
• Auf Anforderung: wenn Kunden, Partner oder Auditoren einen aktuellen Pentest-Bericht verlangen.
• Als wiederkehrende Prüfung: deine Anwendung entwickelt sich laufend weiter, regelmäßige Tests halten das Sicherheitsniveau mit der Entwicklung Schritt.

Unsere Methodik: vom Scoping bis zum Retest

Ein Web Application Pentest läuft bei uns in vier Schritten ab. Du weißt zu jedem Zeitpunkt, was passiert und was als Nächstes kommt.

1. Scoping

Im gemeinsamen Kickoff legen wir fest, welche Anwendungen, Benutzerrollen und Schnittstellen geprüft werden, in welcher Umgebung wir testen und in welchem Zeitfenster. Du bekommst vorab eine klare Liste der Voraussetzungen, etwa Testaccounts und benötigte Freischaltungen, damit der Test ohne Verzögerung starten kann.

2. Testdurchführung: White, Grey oder Black Box

Die Testtiefe richtet sich nach dem gewählten Ansatz:

• White-Box: voller Einblick inklusive Quellcode oder Architektur-Dokumentation. Maximale Testtiefe pro Testtag.
• Grey-Box: Testaccounts für jede relevante Rolle, aber kein Quellcode. Für die meisten Anwendungen der beste Kompromiss, weil Autorisierungsfehler zwischen Rollen sichtbar werden.
• Black-Box: ohne Vorwissen und Zugänge, aus der Perspektive eines externen Angreifers. Realistisch, aber mit der geringsten Testtiefe in derselben Zeit.

Während des Tests melden wir kritische Findings sofort und warten nicht auf den Abschlussbericht.

3. Bericht

Jedes Finding dokumentieren wir mit Schritten zur Reproduktion, einer Risikobewertung und einer konkreten Empfehlung zur Behebung. Der Bericht funktioniert auf zwei Ebenen: technisch präzise für dein Entwicklungsteam, verständlich zusammengefasst für Management und Auditoren.

4. Retest

Nachdem dein Team die Schwachstellen behoben hat, prüfen wir jedes Finding erneut und aktualisieren den Status im Bericht. Damit ist dokumentiert, dass die Lücken tatsächlich geschlossen sind, nicht nur, dass sie gefunden wurden.

Web Application Pentest oder Red Teaming?

Ein Web Application Pentest ist der richtige Ansatz, wenn du eine konkrete Anwendung gezielt absichern willst. Er arbeitet einen definierten Scope ab und deckt dort möglichst viele Schwachstellen auf.

Ein Red Teaming Assessment verfolgt dagegen ein konkretes Ziel über alle Vektoren hinweg, von Technik über Social Engineering bis zum physischen Zutritt, und testet zusätzlich, wie gut deine Verteidigung den Angriff erkennt. Red Teaming lohnt sich, wenn die grundlegenden Schwachstellen bereits behoben sind. Der Web Application Pentest ist der passendere und günstigere Einstieg, wenn es um eine einzelne Anwendung geht. Beides schließt sich nicht aus: Viele Unternehmen starten mit Pentests und erweitern später auf Red Teaming.

Was du bekommst

• Bericht mit reproduzierbaren Findings: jede Schwachstelle mit Schritten zur Reproduktion, nachvollziehbar dokumentiert für Technik und Management.
• Risikobewertung je Finding: klare Schweregrade, damit dein Team weiß, was zuerst behoben werden muss.
• Priorisierte Handlungsempfehlungen: konkrete Maßnahmen, sortiert nach Wirkung und Aufwand.
• Retest: erneute Prüfung der behobenen Schwachstellen mit aktualisiertem Berichtsstatus.

Zertifizierte Tester, nachvollziehbare Methodik

Ein Pentest ist nur so gut wie die Person, die ihn durchführt. Unser Team arbeitet mit hoher Zertifizierungsdichte (OSCP, OSEP, OSWE, CRTO, CRTO2). Für Webanwendungen besonders relevant ist die OSWE-Zertifizierung, die den praktischen Nachweis von White-Box-Exploitation auf Code-Ebene verlangt.

Unsere Methodik orientiert sich an etablierten Standards wie dem OWASP Testing Guide und PTES, damit die Ergebnisse vergleichbar und für Auditoren nachvollziehbar sind. Im Erstgespräch zeigen wir dir gerne einen Beispielbericht und erklären unser Vorgehen.

Remote-Tests aus Wien sind der Standard, vor Ort sind wir nach Bedarf, in ganz Österreich, Deutschland und der Schweiz, auf sauberer vertraglicher Grundlage (DSGVO-Auftragsverarbeitung bzw. Schweizer DSG). Einen unabhängigen Marktüberblick geben unsere Vergleiche der Pentest Anbieter in Österreich.

Häufige Fragen

Wie lange dauert ein Web Application Pentest?

Ein typischer Web Application Pentest dauert ein bis drei Wochen, abhängig vom Umfang: Anzahl der Benutzerrollen, Funktionen und Schnittstellen. Eine kleine Anwendung mit wenigen Rollen liegt am unteren Ende, eine umfangreiche Plattform mit mehreren APIs am oberen. Den genauen Aufwand legen wir im Scoping gemeinsam fest.

Was ist der Unterschied zwischen einem Pentest und einem Vulnerability Scan?

Ein Vulnerability Scan ist automatisiert und erkennt bekannte Schwachstellen anhand von Signaturen, inklusive False Positives. Ein Penetrationstest wird manuell durchgeführt: Wir verifizieren jede Schwachstelle, verketten einzelne Findings zu realen Angriffspfaden und finden Fehler in Autorisierung und Business-Logik, die kein Scanner erkennen kann.

Testet ihr in der Produktiv- oder Staging-Umgebung?

Beides ist möglich. Ideal ist eine Staging-Umgebung, die der Produktion möglichst nahekommt: Dort können wir ohne Risiko für laufende Geschäftsprozesse in voller Tiefe testen. Tests in der Produktivumgebung führen wir mit klaren Vorkehrungen durch: abgestimmte Zeitfenster, eigene Testaccounts und Verzicht auf potenziell destruktive Tests.

Welche Zugänge und Voraussetzungen braucht ihr für den Test?

Für einen Grey-Box-Test brauchen wir Testaccounts für jede relevante Benutzerrolle, die URLs der Zielsysteme und eine technische Ansprechperson für Rückfragen. Vorhandene API-Dokumentation beschleunigt den Test. Ein Black-Box-Test ganz ohne Zugänge ist ebenfalls möglich, liefert aber weniger Testtiefe in derselben Zeit.

Wie läuft der Retest ab?

Nachdem dein Team die gemeldeten Schwachstellen behoben hat, prüfen wir jedes Finding erneut und dokumentieren das Ergebnis in einer aktualisierten Version des Berichts. So hast du einen nachvollziehbaren Nachweis für Management, Kunden oder Auditoren, dass die Lücken tatsächlich geschlossen sind.