(Web) Application Pentest

Was ein (Web) Application Pentest abdeckt

Ein Application Pentest ist die systematische Sicherheitsprüfung einer Anwendung in einem klar definierten Scope, egal ob Webanwendung, API, mobile App oder Desktop-Anwendung. 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.

Welche Anwendungen wir testen

Web-Apps sind ein Schwerpunkt, aber nicht der einzige Anwendungstyp, den wir prüfen. Ein (Web) Application Pentest deckt alle gängigen Anwendungsformen ab:

• Webanwendungen: vom klassischen Web-Portal bis zur Single-Page-Application. Der Web Application Pentest nach OWASP Testing Guide bleibt das Kernstück unseres Angebots.
• APIs (REST & GraphQL): als eigenständiges Prüfobjekt oder als Backend einer Web- oder Mobile-App, inklusive Authentifizierung, Autorisierung und Datenpreisgabe.
• Mobile Apps (iOS & Android): orientiert am OWASP MASVS und MASTG, von lokaler Datenspeicherung über Zertifikats-Pinning bis zur Backend-Kommunikation.
• Desktop- & Fat-Client-Anwendungen: Thick Clients unter Windows, macOS oder Linux, inklusive lokaler Rechteprüfung, Update-Mechanismen und Kommunikation mit Server-Komponenten.

Was wir bei Webanwendungen und APIs testen

Den genauen Prüfumfang stimmen wir im Scoping auf deine Anwendung ab. Bei Webanwendungen und APIs sind die Kernbereiche bei jeder Prüfung 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 Konto A die Daten von Konto B lesen oder verändern? Kommt ein Standardkonto 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.

Bei mobilen Apps und Fat Clients kommen die plattformspezifischen Prüfpunkte dazu: lokale Datenhaltung, Absicherung der Kommunikation, Umgang mit Secrets und die Frage, was passiert, wenn Angreifende den Client vollständig kontrollieren.

Wann ein Application Pentest sinnvoll ist

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

• Vor dem Go-live: eine neue Anwendung oder ein Relaunch steht vor dem Release, und du willst wissen, was Angreifende finden, bevor sie es selbst herausfinden.
• Nach größeren Änderungen: neue Authentifizierung, neue API, neues Rollenmodell. Jede Änderung an kritischen Funktionen kann neue Schwachstellen einführen.
• Auf Anforderung: wenn Kundschaft, Partnerunternehmen oder Prüfstellen 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 von externen Angreifenden. 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 Audit-Personal.

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 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 konkrete Ziele über mehrere 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 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.

Zertifiziertes Testteam, 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, dem OWASP MASVS für mobile Apps und PTES, damit die Ergebnisse vergleichbar und in Audits 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 Application Pentest?

Ein typischer 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.

Testet ihr auch mobile Apps und Desktop-Anwendungen?

Ja. Neben Webanwendungen und APIs prüfen wir mobile Apps für iOS und Android, orientiert am OWASP MASVS, sowie Desktop- und Fat-Client-Anwendungen inklusive ihrer Backend-Kommunikation. Der Ansatz bleibt derselbe: manuelle Analyse, reproduzierbare Findings und ein Bericht mit priorisierten Empfehlungen.

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, Kundschaft oder Audits, dass die Lücken tatsächlich geschlossen sind.