Eine fehlende Sicherheitsprüfung an einem GET-Collection-Endpunkt ermöglichte es jedem mit einem einfachen CoopCycle-Konto, das vollständige Adressbuch jedes Stores in einer gemeinsamen Instanz abzurufen. Dabei wurden Namen, Straßenadressen und Postleitzahlen unzähliger Kunden offengelegt. Die Schwachstelle wurde innerhalb von zwei Tagen behoben, und die Nutzer werden dringend gebeten, auf die neueste veröffentlichte Version zu aktualisieren.

Wie das Datenleck zustande kam

CoopCycle – eine Open-Source-Logistikplattform, die von Lebensmittel-Lieferkooperativen genutzt wird – definiert seine API mit dem PHP-Framework API Platform. In diesem Framework muss jede Operation (POST, GET usw.) mit einem Security-Ausdruck gepaart werden; wenn der Ausdruck weggelassen wird, führt das Framework den Code ohne jegliche Autorisierungsprüfung aus.

Die Entwickler schützten die POST-Anfrage, die die Adressliste eines Stores erstellt oder aktualisiert, mit dem Standardausdruck is_granted('edit', object). Dies funktioniert, da sich die Anfrage auf eine einzelne Store-Entität bezieht und dem Framework somit ein konkretes „Objekt“ zur Auswertung liefert.

Die GET-Anfrage, die dieselbe Ressource liest, zielt jedoch auf eine Collection ab: /api/stores/{id}/addresses. Eine Collection besitzt kein einzelnes Objekt, sodass derselbe Ausdruck is_granted('edit', object) nicht angewendet werden kann. Da die Entwickler die Sicherheitszeile weggelassen haben, lieferte das Framework die Adressdaten an jeden authentifizierten Benutzer aus, unabhängig von der Mandantenzugehörigkeit.

Auf einer gemeinsamen CoopCycle-Instanz konnte ein böswilliger Benutzer einfach die Store-IDs iterieren, GET-Anfragen an den Endpunkt senden und die Privatadressen jedes im System gespeicherten Kunden auslesen. Es waren keine zusätzlichen Berechtigungen über ein normales Konto hinaus erforderlich.

Warum der Fehler übersehen wurde

Das Problem war kein einfacher Flüchtigkeitsfehler. Das deklarative Sicherheitsmodell von API Platform bietet keine einfache Möglichkeit, auszudrücken: „Der Benutzer muss demselben Mandanten angehören wie jedes Objekt in der Collection.“ Die fehlende Codezeile befand sich genau dort, wo das Framework die Autorisierung umständlich gestaltete.

Erschwerend kam hinzu, dass die Testsuite des Projekts tatsächlich bestätigte, dass die GET-Antwort, die alle Adressen enthielt, das erwartete Verhalten darstellte. Mit anderen Worten: Die automatisierten Tests bestanden, weil die in den Tests verwendeten Fixtures einen mandantenübergreifenden Zugriff erlaubten und so die Schwachstelle effektiv maskierten. Eine „grüne“ Testsuite vermittelte in diesem Fall ein falsches Sicherheitsgefühl.

Wer gewinnt und wer verliert

  • Kunden: Ihre personenbezogenen Daten (PII) – vollständige Namen und Privatadressen – wurden für jeden auf der Plattform offengelegt. Obwohl die Daten nicht öffentlich gepostet wurden, gefährdete der Verstoß die Privatsphäre über mehrere Kooperativen hinweg.
  • Kooperativen, die CoopCycle nutzen: Das Vertrauen in die Fähigkeit der Plattform, Mandantendaten zu schützen, wurde erschüttert. Jede Kooperative, die noch nicht aktualisiert hatte, lief Gefahr, weiterhin exponiert zu sein.
  • Die CoopCycle-Maintainer: Ihre schnelle Reaktion – ein Patch innerhalb von zwei Tagen und die Hinzufügung von Regressionstests – begrenzte das Zeitfenster für Exploits und bewies verantwortungsvolle Open-Source-Verantwortung. Der Vorfall verdeutlicht jedoch die Notwendigkeit strengerer Sicherheitsüberprüfungsprozesse, insbesondere bei frameworkgesteuerten Standardeinstellungen.

Worauf Entwickler und Auditoren achten sollten

  • Asymmetrie der Operationen: Wenn eine POST-Anfrage (oder eine andere mutierende Operation) auf einem Pfad geschützt ist, die entsprechende GET-Anfrage jedoch offen steht, ist diese Diskrepanz ein Warnsignal. Die POST-Anfrage zeigt die Absicht der Entwickler, die Ressource zu schützen.
  • Collection-Endpunkte: Alles, was eine Liste statt eines einzelnen Elements zurückgibt, fällt oft aus den üblichen Sicherheitsmustern heraus. Verifizieren Sie, dass Autorisierungsprüfungen explizit für Massenlesevorgänge (Bulk Reads) hinzugefügt wurden.
  • Realismus der Testsuite: Stellen Sie sicher, dass Fixtures die realen Mandantengrenzen widerspiegeln. Ein bestandener Test, der einen mandantenübergreifenden Datenabfluss validiert, ist ein Warnzeichen, kein grünes Licht.

Die Behebung und nächste Schritte

Nachdem die Schwachstelle gemeldet wurde, fügte das CoopCycle-Kernteam den fehlenden Security-Ausdruck zur GET-Collection-Operation hinzu und führte Regressionstests ein, die die Mandantentrennung sowohl für Einzelobjekte als auch für Collection-Endpunkte erzwingen. Der Patch wurde mit einer nachfolgenden Softwareversion veröffentlicht.

Nutzer von CoopCycle sollten:

  1. Überprüfen, ob sie eine aktuelle Version der Software verwenden.
  2. Alle benutzerdefinierten Erweiterungen oder Plugins überprüfen, die ähnliche Lücken auf Collection-Ebene verursachen könnten.
  3. Sicherheits-Scans erneut durchführen, mit einem Fokus auf Asymmetrien zwischen Lese- und Schreibzugriffen über alle API-Routen hinweg.

Fazit

Frameworks, die Sicherheit deklarativ gestalten, können gefährliche Lücken verbergen, wenn sich Entwickler auf Muster verlassen, die nur für einzelne Objekte funktionieren. Eine einfache Prüfung – verfügt die Leseseite eines Endpunkts über dieselbe Absicherung wie die Schreibseite? – kann eine ganze Klasse von Cross-Tenant-Leaks aufdecken, die ansonsten hinter grünen Test-Suites verborgen blieben.