Beispielbericht · Fiktive Szenarien

Was Angreifer erreichen könnten – und wie Sie es verhindern

Diese fiktiven Szenarien orientieren sich an realen Arten von Sicherheitsproblemen. Domains, Konten, Antworten und Prüfverläufe sind erfunden. Sie sind keine Kundenergebnisse und kein Nachweis, dass EverBreach diese Tests durchgeführt hat.

Wo Handlungsbedarf besteht

Im Bewerbungsportal kann ein normales Bewerbungskonto Daten und Lebenslauf einer anderen Person lesen. Im Fotoshop kann ein Besucher ohne Bezahlung ein Bild in voller Auflösung abrufen. Beide Fehler liegen auf der Serverseite. Ein versteckter Button würde den Zugriff nicht verhindern.

Hoch · Zugriff sofort begrenzen
Ein Bewerbungskonto kann fremde Bewerbungsdaten lesen
Verantwortliches Team: Entwicklung und Verantwortliche des Bewerbungssystems
Zugriff auf Bewerbungslisten und Lebensläufe begrenzen, bis die Berechtigungsprüfungen korrigiert sind.
Hoch · Unbezahlten Zugriff sperren
Originalbilder sind schon vor der Bezahlung abrufbar
Verantwortliches Team: Shop-Entwicklung und Verantwortliche für Speicher/CDN
Originale privat speichern und unbezahlten Besuchern keine nutzbaren Downloadlinks mehr ausliefern.

Umfang dieses Beispiels

Zwei getrennte Beispielumgebungen: ein Bewerbungsportal und ein Fotoshop. Verwendet werden angelegte Testbewerbungen, fiktive Lebensläufe, Testbilder und Konten mit vereinbarten Rollen. Es werden keine echten Bewerbungsdaten oder kostenpflichtigen Inhalte abgerufen.

Hoch · Zugriff sofort begrenzen

1. Ein Bewerbungskonto kann fremde Bewerbungsdaten lesen

Verantwortliches Team: Entwicklung und Verantwortliche des Bewerbungssystems
Sofortmassnahme: Zugriff auf Bewerbungslisten und Lebensläufe begrenzen, bis die Berechtigungsprüfungen korrigiert sind.

Folgen für die Organisation

Namen, Kontaktdaten und Lebensläufe geben Einblick in den beruflichen Werdegang und weitere persönliche Informationen. Angreifer könnten sie für gezielten Betrug nutzen oder veröffentlichen. Betrifft die fehlende Prüfung den gesamten Bewerbungseingang, könnten alle neuen Bewerbungen betroffen sein. Der begrenzte Test unten belegt diesen Gesamtumfang nicht.

Was nachgewiesen wurde

Konto A erhielt die angelegten Testbewerbungen A und B und lud den fiktiven Lebenslauf von B herunter. Ohne Anmeldung kam 401 zurück. Es fehlt die Prüfung, worauf ein angemeldetes Konto zugreifen darf; die Anmeldung selbst wurde nicht umgangen. Nach zwei vereinbarten Datensätzen wurde gestoppt.

So könnten Angreifer vorgehen

Ein normales Bewerbungskonto anlegen oder verwenden. Recruiting-Rechte sind nicht nötig.
Die vom Portal verwendete Bewerbungsliste abrufen. Der Server liefert neben dem eigenen auch einen fremden Datensatz.
Mit der zurückgegebenen Kennung den fremden Lebenslauf anfordern. Wiederholungen könnten weitere Datensätze offenlegen. Eine massenhafte Sammlung wurde nicht durchgeführt.

Warum es bei dieser Prüfung auffiel

Beispielhafter Anlass: eine neue Anwendungsversion. Dasselbe Testkonto mit denselben Testdaten erhielt in r41 an der Listenroute 403, in r42 hingegen 200. In dieser Rekonstruktion zeigt der Änderungsvergleich eine neue Route ohne Recruiting-Prüfung. Modell und Testaufbau blieben gleich. Entscheidend war die Anwendungsänderung.

Belege und Behebung

Beispielumgebung: careers.example.com · Release r42

Beispielhafte Anfrage und Antwort

GET /api/applications?status=new
Session: applicant_test_A (no recruiter role)
HTTP 200
[{id:"test-A", email:"a@example.com"},
 {id:"test-B", email:"b@example.com"}]

GET /api/applications/test-B/cv
Session: applicant_test_A
HTTP 200 · application/pdf (synthetic CV)

Control: no session -> HTTP 401

Warum der Zugriff möglich war

Die Listenroute prüft nur, ob eine gültige Sitzung besteht. Sie verlangt keine Recruiting-Rolle und begrenzt die Datensätze nicht auf ihre Eigentümer. Auch beim Lebenslauf-Download fehlt diese Prüfung pro Objekt. Schwer erratbare Kennungen reichen nicht: Die Liste liefert sie bereits mit.

Die Ursache beheben

Bewerbungskonten vorläufig von Listen- und Dokumentrouten ausschliessen. Relevante Zugriffsprotokolle sichern und klären, seit wann die betroffene Version erreichbar war.
Gesamtlisten serverseitig nur für berechtigte Recruiting-Mitarbeitende freigeben. Bewerbende dürfen nur ihre eigenen freigegebenen Daten lesen. Dieselbe Regel auf Lebensläufe und direkte Speicherzugriffe anwenden.
Tests mit Konto A, Konto B, berechtigtem Recruiting-Konto und ohne Anmeldung ergänzen. Listen, Details, Exporte und Anhänge abdecken; Zugriff standardmässig verweigern.
Protokolle auf unberechtigte Zugriffe prüfen und die Verantwortlichen für Sicherheitsvorfälle und Datenschutz zur Bewertung einer tatsächlichen Offenlegung hinzuziehen. Persönliche Daten nicht in normale Tickets kopieren.

Abnahmekriterien für die Nachprüfung

Konto A kann die vorgesehenen eigenen Funktionen nutzen, erhält für Daten und Lebenslauf von B aber 403 oder 404 ohne Dateninhalt. Listen sind für Bewerbungskonten gesperrt. Berechtigte Recruiting-Konten behalten den vorgesehenen Zugriff; anonyme Anfragen scheitern. Direkte Dateizugriffe scheitern ebenfalls. Diese Fälle dauerhaft testen.

Im Beispiel bestätigt: Zugriff auf zwei angelegte Bewerbungsdatensätze und einen fremden fiktiven Lebenslauf. Nicht belegt: Zugriff auf alle Bewerbungen, frühere missbräuchliche Nutzung oder eine offengelegte Produktionsdatenbank.

OWASP · Fehlende Berechtigungsprüfung pro Objekt

Hoch · Unbezahlten Zugriff sperren

2. Originalbilder sind schon vor der Bezahlung abrufbar

Verantwortliches Team: Shop-Entwicklung und Verantwortliche für Speicher/CDN
Sofortmassnahme: Originale privat speichern und unbezahlten Besuchern keine nutzbaren Downloadlinks mehr ausliefern.

Folgen für die Organisation

Der Shop liefert das Produkt aus, bevor der Verkauf abgeschlossen ist. Besucher könnten Originale ohne Kauf speichern oder weitergeben. Nutzen andere Katalogeinträge dieselben Antworten und Speicherregeln, könnten viele Bilder betroffen sein. Gezeigt wird ein vereinbartes Testbild, kein Download des gesamten Katalogs.

Was nachgewiesen wurde

Ein Testkonto ohne Käufe erhielt in der Bildantwort die Adresse des Originals. Eine separate Anfrage ohne Anmeldung lud das Testbild in voller Auflösung. Die Bestellung blieb unbezahlt; es wurde keine Zahlung ausgelöst.

So könnten Angreifer vorgehen

Die Kaufseite eines Fotos ohne abgeschlossenen Kauf öffnen.
Die Bildinformationen prüfen, die vor dem Bezahlvorgang an den Browser gehen. Sie enthalten die Originaladresse, obwohl die Seite nur eine Vorschau anzeigt.
Diese Adresse direkt anfordern. Der Dateiserver liefert das Original ohne Kaufprüfung. Für eine Aussage über den gesamten Katalog müssten weitere Bilder geprüft werden.

Warum es bei dieser Prüfung auffiel

Beispielhafter Anlass: eine Nachprüfung nach einem Modellwechsel. Release r17, Konten, Testdaten, Werkzeuge, Anweisungen und Testbudget bleiben gleich. Der spätere Lauf verfolgt den Link von der Vorschau zum Original; der frühere meldete das Problem nicht. Die Lücke bestand bereits. Zwei einzelne Läufe beweisen nicht, dass der Modellwechsel die Verbesserung verursacht hat. Dafür wären wiederholte vergleichbare Tests nötig.

Belege und Behebung

Beispielumgebung: studio.example.com + media.example.com · Release r17

Beispielhafte Anfrage und Antwort

GET /api/photos/test-photo-01
Session: buyer_test_A · purchases: []
HTTP 200
{"previewUrl":"/previews/test-photo-01.jpg",
 "originalUrl":"https://media.example.com/originals/test-photo-01.jpg"}

GET originalUrl · no session
HTTP 200 · image/jpeg · full resolution
Order state: unpaid · no payment submitted

Warum der Zugriff möglich war

Die Oberfläche versteckt den Downloadbutton bis zur Zahlung. Die API liefert den Originallink aber schon vorher, und der Dateiserver stellt die Datei öffentlich bereit. Es fehlen zwei Kontrollen: die Kaufberechtigung in der Anwendung und der private Zugriff am Dateispeicher.

Die Ursache beheben

Öffentlichen Zugriff auf Originale im Speicher und CDN sperren. Öffentlich zwischengespeicherte Kopien und bereits ausgegebene Zugriffslinks soweit anwendbar ungültig machen. Vorschauen verfügbar lassen.
Unbezahlten Besuchern Vorschauen liefern. Vor jedem Originalzugriff den Zahlungsstatus serverseitig beim Zahlungsanbieter bestätigen und die Kaufberechtigung für genau dieses Bild prüfen. Einer Erfolgsseite oder einem vom Browser gemeldeten Zahlungsstatus nicht vertrauen.
Originale über eine Route mit Berechtigungsprüfung ausliefern oder erst danach kurz gültige, auf die Datei begrenzte signierte Links erzeugen. Wer einen solchen Link besitzt, kann ihn bis zum Ablauf nutzen. Deshalb niemals vor der Bezahlung ausgeben.
Unbezahlte, ausstehende, fehlgeschlagene und abgebrochene Zahlungen sowie einen gültigen Kauf und den Zugriff auf ein anderes Bild testen. Der Dateiserver darf die Entscheidung der Anwendung nicht umgehen.

Abnahmekriterien für die Nachprüfung

Ohne Kauf gibt es nur eine Vorschau und keinen nutzbaren Originallink. Direkte Originalzugriffe scheitern. Ausstehende, fehlgeschlagene und abgebrochene Zahlungen geben nichts frei. Ein bestätigter Käufer kann nur das gekaufte Bild herunterladen. Abgelaufene Links funktionieren nicht mehr; öffentliche Vorschauen weiterhin schon.

Im Beispiel bestätigt: ein Original-Testbild ohne Zahlung abgerufen. Nicht belegt: Zugriff auf alle Bilder, tatsächlicher Umsatzverlust oder ein Erkennungsvorteil eines bestimmten Modells.

OWASP · Transaktionsberechtigung

Aus Ergebnissen konkrete Aufgaben machen

Beispiel für Ihr internes Team oder einen externen Dienstleister. Übernehmen Sie nur die für Ihr System relevanten Punkte und hängen Sie den echten Bericht an.

Guten Tag Bitte prüfen Sie die beigefügten Ergebnisse und benennen Sie für jedes relevante Problem eine verantwortliche Person. BEWERBUNGSPORTAL: Listen nur für berechtigte Recruiting-Mitarbeitende freigeben. Berechtigungen für jede Bewerbung und jeden Lebenslauf-Download prüfen. Relevante Protokolle sichern und den möglichen Zeitraum der Offenlegung klären. FOTOSHOP: Originaldateien privat speichern. Downloads erst nach serverseitiger Zahlungsbestätigung und Prüfung der Berechtigung für das konkrete Bild freigeben. Speicher und CDN prüfen. Bitte bestätigen Sie Sofortmassnahme, dauerhafte Korrektur, Kosten und Zieltermin vor der Umsetzung. Nehmen Sie die erlaubten und verweigerten Zugriffe aus dem Bericht in Regressionstests auf und vereinbaren Sie anschliessend eine Nachprüfung. Vielen Dank.

Was dieser Bericht nicht aussagt

Die Szenarien zeigen die Tiefe einer Anwendungsprüfung, nicht den Prüfumfang des aktuellen externen Scanners. Für einen echten Auftrag müssen Zugänge, Testkonten, erlaubte Aktionen und Abbruchkriterien separat vereinbart werden. Die Beispiele belegen begrenzte Zugriffe auf Testdaten. Sie sagen nichts über einen tatsächlichen Einbruch, die gesamte Exposition oder die allgemeine Erfolgsquote eines KI-Modells aus.

Was die Prüfung umfasst Pilotprüfung anfragen