Referenzen
Beispielbericht: Web- und API-Penetrationstest
So werden technische Schwachstellen in eine belastbare Entscheidungsgrundlage für Management, Entwicklung und Betrieb überführt.
Diese Arbeitsprobe ist vollständig synthetisch. Organisation, Systeme, Personen, Befunde, Kennzahlen, Requests und Zeitangaben sind frei erfunden. Sie enthält keine Kunden- oder Prüfungsdaten.
Vollständiger Beispielbericht
Der Musterbericht zeigt exemplarisch, wie ich die Ergebnisse eines Web- und API-Penetrationstests für unterschiedliche Zielgruppen aufbereite. Er verbindet eine kompakte Management Summary mit einer nachvollziehbaren Angriffskette, reproduzierbarer technischer Evidenz und einem priorisierten Maßnahmenplan.
Beispielbericht als PDF herunterladen
Der fiktive Prüfgegenstand ist ein B2B-Vertragsportal mit REST-API, drei Benutzerrollen und mandantengetrennten Geschäftsdaten. Die Prüfung umfasst keine realen Systeme oder Daten. Der Beispielscope ist bewusst stark abgegrenzt; Aufwand und Ergebnisformat werden in realen Projekten nach Umfang, Rollenmodell und Abstimmungsbedarf separat kalkuliert.
Management Summary
Im vereinbarten Testumfang wurde eine fiktive B2B-Webanwendung mit zugehöriger API und drei Benutzerrollen untersucht. Ausgangspunkt war ein gewöhnliches Kundenkonto. Die zentrale Angriffskette lautete: Kundenkonto → SSRF → überprivilegiertes Service-Token → mandantenweiter Export. Sie führte zu einem kritischen Gesamtrisiko, weil sich zwei Befunde kombinieren ließen:
- Eine Server-Side Request Forgery im URL-Import ermöglichte den Zugriff auf eine interne Administrationsschnittstelle.
- Ein dort offengelegtes, zu weit berechtigtes Service-Token erlaubte über einen extern erreichbaren, token-geschützten Endpunkt mandantenübergreifende Exportabfragen.
Unabhängig davon legte eine fehlende objektbezogene Autorisierung (BOLA) Metadaten und Dokumente eines anderen Mandanten offen. Dieser eigenständige hohe Befund war keine Voraussetzung für die kritische Angriffskette.
Der Nachweis wurde nach einer kleinen synthetischen Stichprobe beendet. Ein vollständiger Datenexport wurde nicht durchgeführt. Auf Grundlage des geprüften Scopes erscheint eine vollständige Neuentwicklung zur Behebung der dokumentierten Befunde nicht erforderlich. Die Angriffskette kann durch eine abgesicherte URL-Verarbeitung und minimal berechtigte technische Identitäten gezielt unterbrochen werden. Die BOLA erfordert zusätzlich eine zentrale Mandantenautorisierung.
Befundübersicht
| Risiko | Anzahl | Entscheidungsbedarf |
|---|---|---|
| Kritisch | 1 | Sofort eindämmen und vor dem nächsten Release beheben |
| Hoch | 2 | Kurzfristig korrigieren und priorisiert retesten |
| Mittel | 1 | Im nächsten Wartungszyklus behandeln |
| Niedrig | 1 | Mit regulärer Härtung umsetzen |
Beispiel-Finding: Fehlende objektbezogene Autorisierung
Risiko: Hoch
Betroffener Bereich: API-Endpunkt für fiktive Vertragsdokumente
Voraussetzung: Beliebiges angemeldetes Kundenkonto
Auswirkung: Ein Benutzer könnte durch Änderung einer Objekt-ID auf Dokumente eines anderen Mandanten zugreifen. Dadurch wären Vertraulichkeit und Mandantentrennung verletzt.
Die Benutzeroberfläche zeigte nur eigene Dokumente. Die serverseitige API band das angeforderte Objekt jedoch nicht an den Mandanten der Sitzung. Der vollständige Bericht dokumentiert hierzu eine bereinigte Beispielanfrage, die beobachtete Antwort, das erwartete Verhalten und die Reproduzierbarkeit.
Empfehlung: Die Zugriffsentscheidung muss serverseitig für jedes Objekt aus der authentifizierten Identität und der zulässigen Mandantenzuordnung abgeleitet werden. Objekt und Mandant sollten bereits in derselben Datenbankabfrage gebunden werden. Ergänzend gehören Negativtests für rollen- und mandantenfremde Objektzugriffe in die automatisierte Teststrecke.
Was der vollständige Bericht zeigt
- Management Summary mit geschäftlicher Auswirkung und Freigabeempfehlung
- vereinbarten Scope, Testrollen, Einschränkungen und Vorgehensweise
- visualisierte Angriffskette aus SSRF und überprivilegiertem Service-Token
- Befundübersicht mit nachvollziehbarer Risikobegründung
- bereinigte HTTP-Requests und Responses als technische Evidenz
- konkrete Maßnahmen für Entwicklung, Architektur und Betrieb
- priorisierten Umsetzungsplan für 24 Stunden, fünf Arbeitstage und mehrere Wochen
- klare Kriterien für einen fokussierten Retest
- positive Beobachtungen mit Kennzeichnung der Evidenzquelle und vorhandene Sicherheitskontrollen
Priorisierter Maßnahmenplan
- URL-Import bis zur wirksamen Zielvalidierung deaktivieren oder streng begrenzen.
- Betroffenes Service-Token widerrufen, Nutzung prüfen und Berechtigungen minimieren.
- Objektbezogene Autorisierung zentral korrigieren und abhängige Endpunkte prüfen.
- Automatisierte Negativtests für Rollen, Mandanten und direkte Objektzugriffe ergänzen.
- Korrekturen in einer kontrollierten Testumgebung gegen die vollständige Angriffskette und den eigenständigen BOLA-Befund retesten.
Vollständigen Beispielbericht als PDF ansehen
Ihr nächster Schritt
Wenn Sie für Ihre Anwendung eine vergleichbare Entscheidungsgrundlage benötigen, nennen Sie mir Zielsystem, Anlass und gewünschten Zeitraum.