So sieht unser Assessment-Bericht aus
Ein geschwärzter, illustrativer Auszug aus dem Bericht, den Sie am Ende eines Projekts erhalten. Alle Befunde unten sind synthetisch und beziehen sich auf ein fiktives Ziel. Echte Kundendaten kommen hier nicht vor.
- Projekt
- Penetrationstest für Webanwendung und API
- Ziel
- Acme Cloud Platform (illustrativ)
- Testzeitraum
- Ein zweiwöchiges Projekt (relative Angabe, keine festen Termine)
- Einstufung
- Vertraulich (illustratives Beispiel)
- Berichtsversion
- Beispiel v1.0
Management Summary
Vexaro untersuchte die extern erreichbare Webanwendung und die zugehörige API der Acme Cloud Platform im Rahmen eines zweiwöchigen Grey-Box-Projekts. Die Tests folgten dem OWASP Web Security Testing Guide und wurden über automatisierte Werkzeuge hinaus manuell verifiziert.
Gesamtes Risikoprofil: erhöht. Die Anwendung setzt Authentifizierung und Transportsicherheit korrekt durch, wendet die Autorisierung auf Objektebene aber uneinheitlich an. Zwei Befunde sind jeweils einzeln ausnutzbar: eine Insecure Direct Object Reference in der Abrechnungs-API und eine Server-Side Request Forgery in der Dokumentenimport-Funktion. Verkettet würden sie einem authentifizierten Benutzer mit geringen Rechten erlauben, die Rechnungen anderer Mandanten zu lesen und interne Cloud-Metadaten zu erreichen. Die Härtung der Zugriffssteuerung und die Einschränkung ausgehender Abrufe beseitigen den Großteil des Restrisikos.
8 Befunde, bewertet mit CVSS 3.1
Umfang und Methodik
Das Projekt umfasste die produktive Webanwendung, ihre REST-API, das sie hostende Cloud-Konto und den extern erreichbaren Netzwerkperimeter. Die Tests waren zeitlich begrenzt und wurden aus einem authentifizierten Konto mit geringen Rechten sowie aus einer nicht authentifizierten Ausgangslage durchgeführt.
- Webanwendung: app.acme.example (authentifizierte und anonyme Abläufe)
- REST-API: api.acme.example (v1- und v2-Endpunkte)
- Cloud-Konto: Objektspeicher, Compute-Metadaten und IAM-Prüfung
- Externer Netzwerkperimeter: exponierte Dienste und TLS-Konfiguration
- Denial-of-Service und volumetrische Lasttests
- Social Engineering und physischer Zugang
- Drittanbieter-SaaS, das nicht vom Ziel betrieben wird
Methodik und Referenzen
Die Tests erfolgten überwiegend manuell und wurden anerkannten Branchenstandards zugeordnet, damit die Befunde reproduzierbar und die Abdeckung nachvollziehbar sind.
Web Security Testing Guide: die Testfälle, nach denen die Anwendung abgedeckt wird.
Application Security Verification Standard: die Prüfgrundlage auf Control-Ebene.
Taktiken und Techniken von Angreifern, um realistische Angriffspfade einzuordnen.
Penetration Testing Execution Standard: der übergreifende Projektablauf.
Jeder Befund wird mit CVSS 3.1 bewertet und in eine Einstufung des Geschäftsrisikos übersetzt. Der Schweregrad spiegelt die Ausnutzbarkeit und die Auswirkung im Kontext dieser Umgebung wider, nicht den Basiswert allein.
Befunde
Acht repräsentative Befunde aus dem Projekt, nach Schweregrad geordnet. Der erste ist unten vollständig ausgeführt, um den Detailgrad jedes Berichtseintrags zu zeigen.
| ID | Befund | Schweregrad | CVSS | Status |
|---|---|---|---|---|
| ACME-2024-001 | IDOR in der Abrechnungs-API legt Rechnungen anderer Mandanten offen | Hoch | 8.1 | Offen |
| ACME-2024-002 | Server-Side Request Forgery im Dokumentenimport | Hoch | 7.7 | Offen |
| ACME-2024-003 | Gebrochene Autorisierung auf Funktionsebene an Admin-Endpunkten | Mittel | 6.5 | Behoben, erneut getestet |
| ACME-2024-004 | Stored XSS im Betreff-Feld von Support-Tickets | Mittel | 5.4 | Offen |
| ACME-2024-005 | Schwache Passwortrichtlinie erlaubt triviale Zugangsdaten | Niedrig | 3.7 | Offen |
| ACME-2024-006 | Ausführliche API-Fehler verraten Stack Traces und Bibliotheksversionen | Niedrig | 3.1 | Risiko akzeptiert |
| ACME-2024-007 | Fehlende Security-Header (HSTS, CSP, frame-ancestors) | Info | 2.4 | Behoben, erneut getestet |
| ACME-2024-008 | Session-Cookie ohne das Attribut Secure ausgestellt | Info | 2.0 | Offen |
Beispielerkenntnis in voller Tiefe
Ein Befund, so ausführlich dargestellt wie jeder Eintrag in einem echten Bericht: Beschreibung, Auswirkung, Nachweis, Reproduktion, Behebung und Referenzen.
IDOR in der Abrechnungs-API legt Rechnungen anderer Mandanten offen
- Befund-ID
- ACME-2024-001
- CVSS 3.1
- 8.1 (Hoch)
- Vektor
- AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N
- CWE
- CWE-639: Authorization Bypass Through User-Controlled Key
Beschreibung
Die Abrechnungs-API gibt Rechnungsdokumente anhand einer fortlaufenden numerischen Kennung zurück, die im Anfragepfad übergeben wird. Der Endpunkt authentifiziert den Aufrufer, prüft aber nie, ob die angeforderte Rechnung zum Mandanten des Aufrufers gehört. Jeder authentifizierte Benutzer kann daher die Kennung durchzählen und Rechnungen anderer Organisationen abrufen, einschließlich der Namen von Abrechnungskontakten, Beträge und Positionen.
Auswirkung
Dies ist eine mandantenübergreifende Verletzung der Vertraulichkeit. Ein authentifizierter Benutzer mit geringen Rechten aus einem beliebigen Mandanten kann die Finanzdaten jedes anderen Mandanten lesen, indem er eine einzige Ganzzahl hochzählt. Die offengelegten Daten umfassen Geschäftskonditionen und persönliche Kontaktdaten und schaffen damit sowohl ein Datenschutzrisiko als auch eine Gefahr durch Wettbewerbsspionage. Da die Kennungen fortlaufend sind, kann der gesamte Rechnungsbestand in Minuten programmgesteuert abgegriffen werden.
Nachweis
Illustrative Anfrage und Antwort. Host, Token und Werte sind synthetisch und geschwärzt.
GET /v2/invoices/10428 HTTP/1.1
Host: api.acme.example
Authorization: Bearer eyJhbGciOi...REDACTED.SAMPLE.TOKEN
Accept: application/jsonHTTP/1.1 200 OK
Content-Type: application/json
{
"invoice_id": 10428,
"tenant_id": 3304,
"bill_to": "[REDACTED], Northwind Trading",
"amount_due": "14,920.00 USD",
"status": "unpaid"
}'Schritte zur Reproduktion
- 1Authentifizieren Sie sich an der Anwendung mit einem beliebigen gültigen Konto mit geringen Rechten und erfassen Sie das Bearer-Token.
- 2Rufen Sie Ihre eigene Rechnung ab, z. B. GET /v2/invoices/10427, und bestätigen Sie eine 200-Antwort.
- 3Verringern oder erhöhen Sie die numerische Kennung (.../10428, .../10429) und wiederholen Sie die Anfrage mit Ihrem eigenen Token.
- 4Beobachten Sie, dass Rechnungen mit anderen tenant_id-Werten zurückgegeben werden, was die fehlende Autorisierungsprüfung auf Objektebene bestätigt.
Behebung
Erzwingen Sie bei jeder Anfrage eine Autorisierung auf Objektebene: Lösen Sie die Rechnung auf und bestätigen Sie dann, dass ihre tenant_id mit dem Mandanten des authentifizierten Principals übereinstimmt, bevor Daten zurückgegeben werden, andernfalls antworten Sie mit 404. Wenden Sie die Prüfung zentral an (etwa in einer Policy-Schicht oder einem Query-Scope) statt je Handler und fügen Sie einen Regressionstest hinzu, der sicherstellt, dass eine mandantenübergreifende Anfrage abgewiesen wird. Fortlaufende Kennungen durch nicht erratbare zu ersetzen verringert die Aufzählung, ist aber Defense-in-Depth und kein Ersatz für die Autorisierungsprüfung.