Kunde B ändert den Abschlag von Kunde A. Sitzung gültig, Token gültig, Antwort 200 OK. Nichts an dieser einen Anfrage ist technisch falsch. Falsch ist nur, dass der Vertrag Kunde A gehört.

Diese Fehlerklasse heißt in der OWASP API Security Top 10 (2023) Broken Object Level Authorization, kurz API1, und sie ist in Kundenportalen, Ladepunkt-Backends und Einspeise-APIs von Versorgern die Schwachstelle mit der direktesten Folge: Sie berührt Abrechnung, Kundendaten und Netzentgelte. Sichtbar wird sie erst, wenn man zwei Identitäten gegeneinander führt. Dieser Beitrag zeigt fünf typische Angriffsketten, für jede den konkreten Testfall und die Korrektur, und was Sie diese Woche selbst tun können.

Der Beweis ist ein Paar

Ein einzelnes 200 OK beweist nichts. Die Anwendung könnte die Änderung stillschweigend verworfen haben. Belegt ist eine Schwachstelle erst durch drei Anfragen: die Referenz, den Übergriff und die Gegenprobe mit der richtigen Identität.

# 1  Referenz: A liest den eigenen Abschlag
GET   /vertraege/V-100234/abschlag
      Bearer <Token A>
  →   200 {"betrag": 89.00}

# 2  Übergriff: B ändert den Abschlag von A
PATCH /vertraege/V-100234/abschlag
      Bearer <Token B>   {"betrag": 1.00}
  →   200 {"betrag": 1.00}   erwartet: 403

# 3  Gegenprobe: A liest erneut
GET   /vertraege/V-100234/abschlag
      Bearer <Token A>
  →   200 {"betrag": 1.00}   von B geändert

Pfade und Werte sind beispielhaft. Entscheidend ist Schritt 3: Erst die Gegenprobe zeigt, dass B den Zustand von A wirklich verändert hat. Dieselben drei Anfragen sind später der Retest. Wenn die Korrektur greift, endet Schritt 2 mit 403 oder 404 und Schritt 3 zeigt wieder 89,00.

Die Vertragsnummer V-100234 muss B dafür nicht erraten. Sie steht auf jeder Rechnung, jedem Abschlagsplan und oft im Betreff einer E-Mail. Eine Kennung, die auf Papier steht, ist öffentlich. Sicherheit darf nie davon abhängen, dass sie geheim bleibt.

Was der Test von Ihnen braucht

Den Paartest kann nur führen, wer mehrere Identitäten mit eigenen Objekten hat. Das ist der einzige Teil, den der Versorger vorbereiten muss, und er wird einmal eingerichtet und dann für jeden Lauf genutzt.

Schreibende Tests treffen nur diese Objekte, nie echte Kunden. Gegen diese Identitäten läuft dann die Frage, die jede der fünf Ketten trägt: Darf diese Identität dieses Objekt mit dieser Funktion berühren?

Fünf Angriffsketten mit Testfall

Wann testen: nach jedem Release, das Rollen oder Objekte ändert

Alle fünf Ketten entstehen mit einer Änderung: ein neues Feld, ein neuer Endpunkt, eine neue Rolle. Beim jährlichen Pentest bleibt eine solche Lücke im Mittel sechs Monate offen und ausnutzbar. Mit einem Test nach jedem Release sind es Tage plus die eigene Behebungszeit.

So sieht das in der Praxis aus. Das Kundenportal bekommt am Dienstag die Funktion „Abschlag ändern“. Am Mittwoch liegt der Befund vor, mit genau dem Anfragepaar von oben. Die Entwicklung ergänzt die Besitzprüfung, am Donnerstag wiederholt der Retest dieselben drei Anfragen, Schritt 2 endet mit 403, die Korrektur geht in Betrieb.

Was Sie diese Woche tun können

1. Eine Anwendung wählen. Die, die am häufigsten geändert wird und deren Fehler Geld berühren: meist das Kundenportal oder seine API.
2. Zwei Testkunden anlegen. Je ein Testvertrag mit Testzähler, dazu ein Mitarbeiterkonto. Das ist die Grundlage für jeden Paartest, manuell wie autonom.
3. Kennungen inventarisieren. Welche Kunden-, Vertrags-, Zähler- und Ladepunktnummern stehen auf Rechnung, Typenschild oder QR-Code? Diese Liste behandeln Sie als öffentlich.
4. Den Paartest einmal selbst führen. In der Testumgebung, mit den beiden Testkunden: einen Endpunkt mit Objektkennung im Pfad nehmen, die Anfrage als A in den Entwicklerwerkzeugen des Browsers kopieren und mit dem Token von B wiederholen. Gegenprobe als A. Das dauert eine Viertelstunde und zeigt, wo Ihr Portal steht.
5. Eine Frage in den Release-Prozess schreiben. „Ändert dieses Release Rollen, Objekte oder Zustandsübergänge?“ Bei Ja wird getestet, bevor die Lücke Monate alt wird.
6. Den Retest zum Abnahmekriterium machen. Eine Korrektur gilt erst als geschlossen, wenn dieselbe belegte Anfrage abgewiesen wird.

SQUR führt diese Paartests autonom: Der Agent erkundet Funktionen und Objektbeziehungen, führt jede gefundene Funktion mit fremden Identitäten erneut aus und liefert jede bestätigte Schwachstelle mit dem Anfragepaar, das sie belegt, in 24 Stunden.

Der Fachbeitrag für Energieversorger

Wie Sie daraus einen Takt für ein ganzes Portfolio ableiten, was Sie von einem Anbieter Autonomer Pentests verlangen sollten und wie der Nachweis gegenüber Aufsicht und Geschäftsleitung aussieht, steht im Fachbeitrag „Autonome Pentests für Energieversorger: Sicherheit im Takt Ihrer Releases“, mit Checkliste und Rechenblatt für das Expositionsfenster.

Fachbeitrag herunterladen →