Web Penetration Testing

Webanwendungen sind die zentrale Schnittstelle nach außen und damit ein beliebtes Angriffsziel. Wir simulieren reale Angriffe auf Ihre Anwendungen und APIs und decken auf, was sich davon tatsächlich ausnutzen lässt, statt nur eine Liste theoretischer Schwachstellen zu liefern.

Test anfragen Verfahren, Methodik und Berichtsumfang

Web Application
Pentesting

Offensive Security

Prüfobjekt

Webanwendungen und APIs

Grundlage

OWASP Top 10 und WSTG

Perspektive

unauthentifiziert bis privilegiert

Voraussetzung

Testsystem und Testkonten je Rolle

Wann ein Webtest ansteht

Eine neue Anwendung, ein Portal oder ein Shop geht live.
Ein Kunde verlangt vor der Freigabe einen Testbericht für die Anwendung.
Nach einem größeren Release, besonders wenn Authentifizierung oder Rechtelogik angefasst wurden.
Die Anwendung verarbeitet personenbezogene oder zahlungsrelevante Daten.
Eine externe Agentur hat entwickelt und Sie wollen den Stand unabhängig prüfen lassen.
Ein Audit nach ISO 27001, BSI-Grundschutz oder NIS2 verlangt einen Nachweis für kritische Anwendungen.
Die Anwendung wurde von einer Monolithen- auf eine Microservice-Architektur mit vielen neuen APIs umgestellt.

Was genau geprüft wird

Webanwendung

Die klassische Prüfung: Login, Formulare, Rechtelogik, Session-Handling und die Frage, was ein Nutzer über seine vorgesehenen Möglichkeiten hinaus erreichen kann.

API

REST- oder GraphQL-Schnittstellen, die vom Frontend genutzt werden, aber oft mehr zulassen, als die Oberfläche zeigt. Ein häufiger Fund: Endpunkte, die im Frontend nicht verlinkt, aber ungeschützt erreichbar sind.

Single-Page-Anwendungen

Anwendungen, bei denen ein Großteil der Logik im Browser läuft. Wir prüfen, ob sicherheitsrelevante Entscheidungen tatsächlich serverseitig getroffen werden oder sich clientseitig umgehen lassen.

Mobile Backend

Ist eine mobile App an dieselbe Serverlogik angebunden, prüfen wir die Schnittstelle unabhängig von der App selbst, da sie oft weniger streng geprüft ist als die Weboberfläche.

Was wir prüfen

Schwachstellenanalyse – systematische Prüfung entlang OWASP Top 10 und WSTG.
Authentifizierung und Session-Handling – Login-Prozesse, Token-Verwaltung, Passwort- und Wiederherstellungsfunktionen.
Rechte- und Rollenlogik – ob ein Benutzer auf Daten oder Funktionen anderer Benutzer zugreifen kann, horizontal wie vertikal.
Eingabeverarbeitung – wie die Anwendung mit unerwarteten oder manipulierten Eingaben umgeht.
APIs – Endpunkte, die im Frontend nicht sichtbar sind, aber offen antworten, inklusive Rate-Limiting und Autorisierung je Endpunkt.
Geschäftslogik – Abläufe, die technisch fehlerfrei funktionieren, aber missbraucht werden können, etwa Rabattlogik oder Bestellprozesse.
Konfiguration – Sicherheitsheader, Fehlerausgaben, offene Debug- oder Adminbereiche.
Exploitation – gezielte Prüfung, ob ein Fund praktisch ausnutzbar ist oder nur theoretisch besteht.

Was wir häufig sehen

Fund	Warum es zählt
SQL-Injektion	Einschleusen von Code in Datenbankabfragen, oft mit Zugriff auf die komplette Datenbank.
Cross-Site-Scripting	Skripte, die im Browser anderer Nutzer ausgeführt werden, bis hin zur Kontoübernahme.
Fehlende Zugriffsprüfung (IDOR)	Fremde Datensätze über eine geänderte ID im Aufruf erreichbar, einer der häufigsten Funde überhaupt.
Unsichere Authentifizierung	Schwache Passwortregeln, fehlende Ratenbegrenzung, unsicheres Session-Handling.
Server-Side Request Forgery	Die Anwendung lässt sich dazu bringen, Anfragen an interne Systeme zu stellen, die von außen sonst nicht erreichbar wären.
Fehlkonfigurierte APIs	Offene Endpunkte ohne Autorisierungsprüfung, oft aus dem Entwicklungsstand übernommen.
Verwundbare Abhängigkeiten	Veraltete Bibliotheken mit bekannten, öffentlich dokumentierten Schwachstellen.
Fehlerhafte Geschäftslogik	Technisch valide Abläufe, die sich zum eigenen Vorteil manipulieren lassen.

„Jede Zeile Code kann ein Einfallstor sein, wenn Sicherheit nicht mitgedacht wird.“

Wie ein Test läuft

Scoping

Wir legen Testumfang, Rollen, Testkonten und Zeitfenster fest, inklusive einer Abstimmung zu Produktiv- oder Testsystem.

Aufklärung

Kartierung der Anwendung: Funktionen, Endpunkte, eingesetzte Technologien und Angriffsfläche.

Schwachstellenanalyse

Systematische Prüfung entlang OWASP WSTG, ergänzt um manuelle Analyse der Geschäftslogik, die kein automatisierter Scanner erfasst.

Ausnutzung

Kontrollierte Prüfung, ob ein Fund praktisch nutzbar ist, ohne dabei echte Daten zu verändern oder zu löschen.

Bericht und Abschlussgespräch

Übergabe der Findings mit Risikoeinstufung, Nachweis und Empfehlung je Fund, gemeinsame Durchsprache mit Ihrem Entwicklungsteam.

Test gegen Produktiv- oder Testsystem

Testsystem

Die bevorzugte Variante. Wir testen mit voller Intensität, ohne Rücksicht auf produktive Nutzerdaten oder laufenden Geschäftsbetrieb nehmen zu müssen. Voraussetzung ist, dass sich das Testsystem funktional wie die Produktivumgebung verhält.

Produktivsystem

Möglich, wenn kein vergleichbares Testsystem existiert. Wir stimmen dann vorab ab, welche Aktionen ausgeschlossen sind, etwa echte Zahlungen oder das Versenden echter Mails, und vermeiden destruktive Prüfungen an Produktivdaten.

Beides sagen wir Ihnen im Scoping-Gespräch offen: Ein Test gegen ein veraltetes Testsystem, das nicht dem Produktivstand entspricht, liefert nur eine Aussage über das Testsystem.

Was Sie bereitstellen

Zugang zur Anwendung, im Idealfall auf einem Testsystem.
Testkonten für jede zu prüfende Berechtigungsstufe, damit Rechteprüfungen möglich sind.
Eine kurze Funktionsübersicht, falls die Anwendung nicht selbsterklärend ist.
Eine technische Ansprechperson aus dem Entwicklungsteam für Rückfragen.
Bei APIs die entsprechende Dokumentation oder Schnittstellenbeschreibung, sofern vorhanden.

Was Sie daraus mitnehmen

Jeder Fund kommt mit Risikoeinstufung, nachvollziehbarem Reproduktionsweg und konkreter Empfehlung, sodass Ihr Entwicklungsteam direkt loslegen kann, ohne den Fund erst selbst nachstellen zu müssen. Funde zur Geschäftslogik erklären wir zusätzlich im Kontext, weil sie sich anders als technische Schwachstellen nicht immer eindeutig einer Standardkategorie zuordnen lassen.