Web Application Penetration Testing: Die Methodik, mit der wir arbeiten

Der beste Fund des letzten Quartals stand nicht im Scanner-Report. Er tauchte in der zähen Stunde nach dem Scan auf, beim vierten Durchgang durch einen Checkout-Flow, als mir auffiel, dass die order_id in einer Bestätigungsanfrage eine schlichte, fortlaufende Ganzzahl war. Eins abziehen. Erneut senden. Zurück kam die Lieferadresse eines fremden Kunden. Genau diese Lücke – zwischen dem, was ein Tool meldet, und dem, was ein Angreifer damit tatsächlich anstellt – ist der Grund, warum unsere Methodik für Web Application Penetration Testing genau so aufgebaut ist, wie sie ist.

Was jetzt folgt, ist der Ablauf, den wir in echten Projekten fahren, keine Folie aus einem Vertriebsdeck. Die Reihenfolge passt sich der jeweiligen Anwendung an. Das Grundgerüst bleibt. Jede Phase liefert der nächsten die Grundlage.

Die wichtigsten Erkenntnisse

• Eine echte Methodik für Web Application Penetration Testing wird manuell geführt. Scanner übernehmen Breite und Grundrauschen; Menschen finden die Fehler bei Zugriffskontrolle und Business Logic, die Tools strukturell nicht sehen können.
• Wir arbeiten in Phasen: Scoping und Recon, Mapping, Authentifizierung und Session, Zugriffskontrolle, Injection, Business Logic, danach Reporting und ein Retest, der bestätigt, dass die Fixes wirklich greifen.
• Die folgenschwersten Funde sind meist fehlerhafte Zugriffskontrolle (IDOR) und Logik-Missbrauch, nicht exotische Speicherfehler. Sie fallen unter OWASP Top 10 A01 und bleiben die häufigsten kritischen Befunde, die wir dokumentieren.
• Ein Fund ohne reproduzierbaren Proof of Concept und ohne konkrete Behebung ist nur ein halber Fund. Der Report ist das Produkt.
• Der Retest zählt genauso viel wie der Test selbst. Ein Ticket mit dem Status “behoben”, das niemand nachgeprüft hat, ist ein häufiger Weg, auf dem eine echte Schwachstelle in Produktion landet.

Was Web Application Penetration Testing wirklich ist

Web Application Penetration Testing ist eine autorisierte, zielgerichtete Angriffssimulation gegen eine konkrete Anwendung, durchgeführt von einem Menschen, der dieselben Tools und dieselbe Denkweise nutzt wie ein echter Angreifer. Es geht nicht um eine Liste theoretischer Schwächen. Es geht darum, nachzuweisen, welche davon sich ausnutzen lassen, wie weit sie reichen und woran ein entschlossener Außenstehender oder ein böswillig angemeldeter Nutzer tatsächlich herankommt.

Dieser Unterschied bestimmt alles Weitere. Ein Scan fragt: Existiert dieses Muster? Ein Pentest fragt: Lässt sich daraus Zugriff auf Daten oder Geld machen? Die zweite Frage ist schwerer. Sie lässt sich schlecht automatisieren. Und genau dort liegt der Wert.

Phase 1: Scope, Rules of Engagement und Recon

Bevor auch nur eine einzige Anfrage rausgeht, halten wir den Scope schriftlich fest. Welche Hostnamen und Subdomains im Spiel sind. Welche Umgebung – wir drängen nachdrücklich auf ein Staging-Abbild statt echter Kundendaten. Welche Rollen wir bekommen, ob wir als nicht authentifizierter Außenstehender testen, als Nutzer mit geringen Rechten oder als beides, und welche Endpunkte tabu sind. Rules of Engagement sind kein Papierkram. Testkonten auf zwei unterschiedlichen Berechtigungsstufen zu bekommen, ist oft der einzige Faktor, der darüber entscheidet, ob wir einen Fehler in der Zugriffskontrolle überhaupt nachweisen können.

Recon kartiert dann die Angriffsfläche. Wir zählen Subdomains auf, ziehen die JavaScript-Bundles und durchsuchen sie nach versteckten API-Routen und fest einprogrammierten Schlüsseln, lesen jede vorhandene Swagger- oder OpenAPI-Definition und erfassen den Stack. Eine moderne Single-Page-App gibt ihren kompletten Backend-Kontrakt bereitwillig in einer JS-Datei mit Source Map preis. Diese Datei sorgfältig zu lesen, schlägt jedes Mal das Raten.

Phase 2: Mapping der Anwendung

Jetzt bedienen wir die Anwendung von Hand, während Burp Suite alles proxyt. Jede Rolle, jeder Workflow, jede Zustandsänderung. Registrieren, anmelden, ein Passwort zurücksetzen, eine Datei hochladen, etwas kaufen, einen Kollegen einladen, eine Rolle ändern, ein Objekt löschen. Die Proxy-History aus einem gründlichen Durchlauf wird zur Karte, von der aus wir angreifen.

Für die Pfade, auf die das UI nie verlinkt, setzen wir ffuf und Burps Crawler zur Content- und Parameter-Erkennung ein. Alte Admin-Panels. Debug-Routen. Ein vergessenes /api/v1, das nie die Autorisierungsprüfungen bekommen hat, die jemand nachträglich an v2 geschraubt hat. Das Letztere begegnet uns ständig.

ffuf -w wordlist.txt -u https://app.example.com/api/FUZZ \
  -H "Authorization: Bearer <low-priv-token>" \
  -mc 200,201,401,403 -o results.json

Phase 3: Authentifizierung und Session-Management

Authentifizierung bekommt einen eigenen Arbeitsstrang, denn hier grob danebenzuliegen ist katastrophal, und subtil danebenzuliegen ist überall anzutreffen. Wir testen Passwort-Reset-Flows auf vorhersagbare Token und Host-Header-Poisoning. Wir prüfen, ob Sessions bei Logout und Passwortwechsel wirklich sterben oder es nur vortäuschen. Wir schauen uns die JWT-Verarbeitung genau an: Algorithm Confusion, fehlende Signaturprüfung, alg: none, Token, die nie ablaufen. Und wir klopfen Multi-Faktor-Flows auf die klassische Lücke ab, bei der der zweite Faktor im UI erzwungen wird, aber nicht beim darunterliegenden API-Aufruf.

Etwas, das wir bei erschreckend vielen Anwendungen sehen: Rate Limiting am Login-Formular, aber keins am JSON-Endpunkt dahinter. Wenn das Frontend drosselt und die API mit den Schultern zuckt, spaziert Credential Stuffing einfach herein.

Phase 4: Zugriffskontrolle – wo die kritischen Funde stecken

Fehlerhafte Zugriffskontrolle ist OWASP Top 10 A01 und die Kategorie, die die meisten unserer kritischen Funde hervorbringt. Der Klassiker ist IDOR (insecure direct object reference, CWE-639): ein Objektbezeichner in einer Anfrage, dem der Server vertraut, ohne je zu prüfen, ob der aktuelle Nutzer dieses Objekt überhaupt besitzt.

Deshalb sind zwei Testkonten wichtig. Wir zeichnen eine Anfrage als Nutzer A auf, spielen sie als Nutzer B erneut ab, indem wir nur die Objekt-ID oder das Session-Token austauschen, und beobachten, ob Nutzer B mit den Daten von Nutzer A davonspaziert.

GET /api/v2/invoices/48213 HTTP/1.1
Host: app.example.com
Authorization: Bearer <user-B-token>

# Invoice 48213 belongs to user A.
# A 200 with A's data means IDOR.

Wir testen außerdem vertikale Rechteausweitung (kann ein Standardnutzer eine reine Admin-Funktion erreichen, indem er den Endpunkt direkt aufruft?), Mass Assignment (bleibt das Hinzufügen von "role":"admin" zu einem Profil-Update-Body tatsächlich haften?) und Forced Browsing zu Funktionen, die das Menü verbirgt, der Server aber weiterhin ausliefert. Scanner übersehen nahezu all das. Sie haben keinerlei Vorstellung davon, wem was gehören soll. Dieser Kontext steckt im Kopf des Testers.

Phase 5: Injection und serverseitige Schwachstellen

Injection ist gut verstanden, und verschwunden ist sie keineswegs. Sie hat sich verlagert. Wir testen weiterhin auf SQL Injection mit manuellen und automatisierten Payloads, aber die Stunden fließen jetzt in die Varianten, die Frameworks nicht für Sie gelöst haben: Server-Side Template Injection, SSRF, bei der ein URL-Parameter den Server dazu bringt, interne Ressourcen abzurufen (eine gerade Linie zu Cloud-Metadaten-Endpunkten), XML External Entity Processing bei allem, was noch XML einliest, und Command Injection, die sich in Dateiverarbeitung oder Export-Funktionen versteckt.

Cross-Site-Scripting ist nach wie vor überall, besonders DOM-basiertes XSS in SPAs, wo ein Wert aus der URL in innerHTML oder eine Framework-Senke ohne jede Bereinigung fließt. Wir bestätigen jeden Kandidaten von Hand. Ein reflektierter Wert in einer Antwort beweist nichts. Die Ausführung im Browser beweist es.

Phase 6: Business Logic – der Teil, den Tools nicht leisten können

Beim Testen der Business Logic trennt Erfahrung ein echtes Assessment von einem Scan-and-Dump-PDF. Es gibt keine Signatur für “der Gutschein wird zweimal angerechnet” oder “man kann den Bezahlschritt überspringen und landet trotzdem in der kostenpflichtigen Stufe” oder “das Mengenfeld akzeptiert eine negative Zahl und schreibt Ihrem Konto gut”. Daraus werden erst dann Funde, wenn ein Mensch versteht, was die Anwendung tun soll, und dann bewusst die dahinterliegende Annahme bricht.

In Projekten finden wir regelmäßig Race Conditions in Einlöse- und Auszahlungs-Flows – dieselbe Anfrage zwanzigmal parallel abfeuern und sehen, ob eine einmalige Aktion zweimal ausgelöst wird. Workflow-Schritte, die sich umsortieren oder überspringen lassen. Limits, die nur clientseitig durchgesetzt werden. Diese Kategorie taucht in automatisierter Ausgabe selten auf, und genau hier steckt oft der größte Schaden in der echten Welt.

Phase 7: Reporting und der Retest

Der Report ist das eigentliche Ergebnis, deshalb schreiben wir ihn für zwei Lesergruppen zugleich. Die Führungsebene bekommt eine nach Risiko sortierte Zusammenfassung in geschäftlicher Sprache. Die Entwickler bekommen eine Aufbereitung pro Fund: Schweregrad (wir bewerten mit CVSS, gleichen ihn aber immer gegen die tatsächliche Ausnutzbarkeit in Ihrem Kontext ab), Schritt-für-Schritt-Reproduktion, die exakte Anfrage oder Payload und eine konkrete Behebung. Nicht “Eingaben bereinigen”. Welche Prüfung hinzuzufügen ist, und wo.

Dann folgt der Retest. Sobald Ihr Team die Fixes ausgeliefert hat, fahren wir exakt die Angriffe erneut, die funktioniert haben, und bestätigen, dass sie tot sind, und prüfen, dass wir nebenan kein neues Loch aufgerissen haben. Aus einem Fund kann man sich nicht herausreden; die Payload feuert entweder oder eben nicht. Eine Behebung, die niemand verifiziert hat, ist der Weg, auf dem eine “geschlossene” Schwachstelle klammheimlich in Produktion gelangt.

Wie CyberXplore unterstützt

Genau diese Methodik fahren wir im Rahmen unseres Service Penetrationstests für Webanwendungen: erfahrene Tester, manuell geführte Arbeit, ein Report, mit dem Ihre Entwickler etwas anfangen können, und ein inklusiver Retest, damit Sie für Fixes bezahlen, die halten, und nicht für ein PDF, das Staub ansetzt. Brauchen Sie Hilfe beim Scoping oder eine klare Aussage zu Aufwand und Zeitrahmen für Ihre Anwendung? Angebot anfordern, und wir gehen Ihre Angriffsfläche gemeinsam mit Ihnen durch, bevor Sie sich auf irgendetwas festlegen.

FAQ

Wie lange dauert ein Penetrationstest für eine Webanwendung?

Für eine typische mittelgroße Anwendung sollten Sie mit etwa ein bis zwei Wochen aktivem Testen plus einigen Tagen für das Reporting rechnen. Der Aufwand skaliert mit der Anzahl der Rollen, Endpunkte und Workflows im Scope. Anwendungen mit viel Business Logic oder vielen Berechtigungsstufen dauern länger, denn das sind die Teile, die man nicht übers Knie brechen kann. Ein sauberes Scoping vorab hält die Schätzung ehrlich.

Was ist der Unterschied zwischen einem Scan und einem Penetrationstest?

Ein Schwachstellen-Scan ist automatisierter Musterabgleich, der bekannte Signaturen meldet und reichlich False Positives erzeugt. Ein Penetrationstest ist ein Mensch, der die Anwendung angreift, um echte, ausnutzbare Auswirkungen nachzuweisen – einschließlich der Fehler bei Zugriffskontrolle und Business Logic, die Scanner nicht erkennen können. Scanner setzen wir innerhalb eines Pentests für die Breite ein. Sie sind der Anfang der Arbeit, nicht ihr Ganzes.

Benötigen Sie Zugang zur Produktion oder eine Staging-Umgebung?

Wir bevorzugen eine Staging- oder Pre-Production-Umgebung, die das Verhalten der Produktion widerspiegelt, idealerweise befüllt mit Testdaten statt echter Kundendaten. So können wir aggressiv testen, ohne Livedaten oder Verfügbarkeit zu riskieren. Steht nur die Produktion zur Verfügung, passen wir die Rules of Engagement an, um sicher zu testen und zerstörerische Aktionen zu vermeiden.

Warum verlangen Sie mehrere Benutzerkonten und Rollen?

Weil die meisten kritischen Funde Fehler in der Zugriffskontrolle sind, und einen solchen weisen Sie ohne zwei Perspektiven nicht nach. Das Testen als Nutzer A und Nutzer B bestätigt, ob der Server die Eigentümerschaft tatsächlich prüft. Das Testen eines Kontos mit geringen Rechten gegen Admin-Funktionen deckt vertikale Rechteausweitung auf. Ohne diese Konten können wir solche Fehler zwar vermuten, aber nicht nachweisen.

Ist ein Retest inklusive?

Ja. Nachdem Ihr Team die Behebung umgesetzt hat, fahren wir die erfolgreichen Angriffe erneut, bestätigen, dass die Fixes halten, und aktualisieren den Status im Report. Ein Fund ist erst dann wirklich geschlossen, wenn jemand verifiziert hat, dass die Behebung funktioniert, und diese Verifikation ist Teil des Projekts und kein Add-on.

Deckt diese Methodik APIs und Single-Page-Apps ab?

Ja. Eine moderne Webanwendung ist meist eine SPA, die mit einer JSON- oder GraphQL-API spricht, also fließt ein Großteil unserer Zeit in die API. Wir zerlegen die Frontend-Bundles, um den Backend-Kontrakt zu kartieren, und testen dann die API-Endpunkte direkt auf Autorisierung, Injection und Logikfehler, statt dem zu vertrauen, was das UI zufällig preisgibt.