VenedyDie Unterschiede auf einen Blick
| BOLA | BFLA | BOPLA | |
|---|---|---|---|
| OWASP 2023 | API1 | API5 | API3 |
| Was nicht geprüft wird | ob der Nutzer genau dieses Objekt sehen oder ändern darf | ob die Rolle diese Funktion ausführen darf | ob der Nutzer dieses einzelne Feld lesen oder schreiben darf |
| Typisches Beispiel | GET /orders/1002 statt der eigenen Bestellung 1001 | ein normaler Nutzer ruft DELETE /admin/users/7 auf | PATCH /users/me mit "role": "admin", oder die Antwort enthält ein internes Feld |
| Folge | Zugriff auf fremde Daten | Admin-Aktionen ohne Admin-Rechte | einzelne Felder werden offengelegt oder manipuliert |
Eine Frage zur Einordnung
Wenn Sie einen Befund einordnen wollen, hilft eine einzige Frage: Was hätte die API prüfen müssen?
- Welches Objekt? Der Nutzer greift auf einen fremden Datensatz zu: BOLA.
- Welche Aktion? Der Nutzer führt eine Funktion aus, die seiner Rolle nicht zusteht: BFLA.
- Welches Feld? Der Zugriff auf das Objekt ist erlaubt, aber nicht auf jede seiner Eigenschaften: BOPLA.
Oft treten sie gemeinsam auf. Ein Endpunkt kann gleichzeitig fremde Objekte liefern (BOLA) und dabei zu viele Felder preisgeben (BOPLA).
Warum Scanner alle drei übersehen
Aus Sicht eines Scanners sieht jeder dieser Fehler nach normalem Verhalten aus. Die API antwortet mit 200 OK und gültigem JSON, ohne Fehlermeldung und ohne verdächtiges Muster. Ob die Antwort ein Fehler ist, hängt allein davon ab, wem das Objekt gehört, welche Rolle der Aufrufer hat und welche Felder er sehen darf. Dieses Wissen steckt in der Geschäftslogik, nicht in einer Signatur.
Dazu kommt: Viele Scanner testen mit einer einzigen Identität. Berechtigungsfehler zeigen sich aber erst im Vergleich. Was darf Nutzer A, was darf Nutzer B, und was darf ein Admin?
So testet man alle drei
Berechtigungsfehler findet man mit mindestens zwei Test-Identitäten, besser mit mehreren Rollen. Das Prinzip ist immer gleich: mit Identität A etwas anlegen, mit Identität B darauf zugreifen.
- BOLA: Objekt-IDs von Nutzer A mit dem Token von Nutzer B abfragen, ändern und löschen.
- BFLA: Jede Funktion mit jeder Rolle aufrufen, auch Admin-Endpunkte und andere HTTP-Methoden auf demselben Pfad, etwa
DELETEstattGET. - BOPLA: Antworten auf Felder prüfen, die die Rolle nicht sehen darf, und beim Schreiben zusätzliche Felder mitsenden (Mass Assignment).
Daraus entsteht eine Matrix aus Identitäten, Endpunkten und Methoden, die mit jedem Release wächst. Venedy spielt genau diese Matrix automatisiert durch: Eine KI plant die Angriffe über mehrere Identitäten, und jeder Befund kommt mit dem HTTP-Beleg. So arbeitet Venedy
Häufige Fragen
Ist IDOR dasselbe wie BOLA?
Im Kern ja. IDOR (Insecure Direct Object Reference) ist der ältere Begriff aus der Welt der Webanwendungen. In den OWASP API Top 10 heißt dasselbe Problem BOLA.
Welcher der drei Fehler ist am häufigsten?
BOLA steht in den OWASP API Top 10 auf Platz 1. OWASP beschreibt ihn als extrem verbreitet in API-basierten Anwendungen.
Kann ein API-Gateway diese Fehler verhindern?
Teilweise. Ein Gateway setzt Authentifizierung, Scopes und den Zugriff auf ganze Endpunkte durch und fängt damit viele BFLA-Fälle ab. Ob ein Nutzer ein bestimmtes Objekt oder Feld sehen darf, weiß aber meist nur die Anwendung selbst. BOLA und BOPLA müssen deshalb in der API geprüft und regelmäßig getestet werden.