VenedyLaut OWASP-Seite (Rating-Tabelle): API Specific. Exploitability (Ausnutzbarkeit) Easy; Prevalence (Verbreitung) Widespread; Detectability (Auffindbarkeit) Easy; Technical Impact (technische Auswirkung) Moderate; Business Impact Business Specific. Threat agents/Attack vectors sind als API Specific gekennzeichnet.
Wie der Angriff funktioniert
Objektbezogene Autorisierung (Object Level Authorization) ist eine Zugriffskontrolle, die laut OWASP üblicherweise auf Code-Ebene umgesetzt wird und sicherstellt, dass ein Nutzer nur auf die Objekte zugreift, für die er Berechtigungen hat. Jeder API-Endpunkt, der eine Objekt-ID empfängt und eine Aktion darauf ausführt, sollte Object-Level-Authorization-Prüfungen implementieren, die validieren, dass der angemeldete Nutzer die angefragte Aktion auf dem angefragten Objekt durchführen darf.
Das Problem ist laut OWASP in API-basierten Anwendungen extrem verbreitet, weil die Server-Komponente den Zustand des Clients meist nicht vollständig verfolgt und sich stattdessen auf Parameter wie Objekt-IDs verlässt, die vom Client gesendet werden, um zu entscheiden, welche Objekte zugänglich sind. Objekt-IDs (fortlaufende Ganzzahlen, UUIDs oder beliebige Zeichenketten) sind im Anfrageziel (Pfad oder Query-Parameter), in Headern oder im Anfrage-Payload leicht zu identifizieren und zu manipulieren.
Laut OWASP ist es by design vorgesehen, dass der Nutzer Zugriff auf den verwundbaren Endpunkt/die Funktion selbst hat - die Verletzung passiert auf Objektebene durch Manipulation der ID. (Verschafft sich ein Angreifer hingegen Zugriff auf einen Endpunkt/eine Funktion, den/die er gar nicht aufrufen dürfte, ist das Broken Function Level Authorization (BFLA), nicht BOLA.)
Der bloße Vergleich der User-ID der aktuellen Sitzung - z. B. extrahiert aus dem JWT-Token - mit dem verwundbaren ID-Parameter ist laut OWASP keine ausreichende Lösung und deckt nur einen kleinen Teil der Fälle ab.
Authentifiziert ja, aber die Objekt-Berechtigung wird nicht geprüft.
Beispiel
OWASP-Szenario 1 (E-Commerce-Plattform): Eine E-Commerce-Plattform für Online-Shops bietet eine Übersichtsseite mit Umsatzdiagrammen für die gehosteten Shops.
- Der Angreifer inspiziert die Browser-Anfragen und erkennt die API-Endpunkte, die als Datenquelle für die Diagramme dienen, samt Muster:
GET /shops/{shopName}/revenue_data.json - Über einen anderen API-Endpunkt beschafft sich der Angreifer die Liste aller gehosteten Shop-Namen.
- Mit einem einfachen Skript ersetzt er
{shopName}in der URL nacheinander durch die Namen aus der Liste. - Der Angreifer erhält dadurch Zugriff auf die Verkaufsdaten tausender E-Commerce-Shops.
Hinweis: Die OWASP-Seite nennt in Szenario 1 nicht explizit, dass die fehlende Prüfung darin besteht, ob der Nutzer Eigentümer des Shops ist - dies ist die implizite Schwachstelle. Die Seite führt zwei weitere Szenarien an: ferngesteuerte Fahrzeuge via VIN, und Löschen fremder Dokumente per GraphQL-Mutation.
Auswirkung
Laut OWASP kann unbefugter Zugriff auf Objekte anderer Nutzer zur Offenlegung von Daten an unbefugte Dritte, zu Datenverlust oder zur Datenmanipulation führen. Unter bestimmten Umständen kann unbefugter Objektzugriff auch zur vollständigen Account-Übernahme (Account Takeover) führen.
Fehler in diesem Mechanismus führen laut OWASP typischerweise zur unbefugten Offenlegung, Veränderung oder Zerstörung sämtlicher Daten. Die geschäftlichen Auswirkungen sind laut OWASP geschäftsspezifisch (Business Specific) - sie hängen davon ab, welche Daten und Funktionen über die betroffenen Objekte erreichbar sind (z. B. Umsatzdaten, Fahrzeugsteuerung, Dokumente).
So schützt man sich
- Einen geeigneten Autorisierungsmechanismus implementieren, der auf Nutzer-Richtlinien (Policies) und der Nutzer-Hierarchie basiert.
- Den Autorisierungsmechanismus in jeder Funktion verwenden, die eine Client-Eingabe nutzt, um auf einen Datensatz in der Datenbank zuzugreifen, und damit prüfen, ob der angemeldete Nutzer die angefragte Aktion auf dem Datensatz ausführen darf.
- Bevorzugt zufällige und nicht vorhersagbare Werte (GUIDs) als Datensatz-IDs verwenden.
- Tests schreiben, die die Verwundbarkeit des Autorisierungsmechanismus bewerten; keine Änderungen ausliefern, die diese Tests fehlschlagen lassen.
Häufige Fragen
Was ist BOLA?
Broken Object Level Authorization (API1:2023) ist das häufigste API-Risiko. Ein Angreifer manipuliert die ID eines Objekts in Pfad, Query oder Body und greift auf fremde Daten zu, weil der Server nicht prüft, ob der Nutzer genau dieses Objekt sehen darf.
Wie verhindert man BOLA?
Mit einer objektbezogenen Autorisierungsprüfung bei jedem Zugriff nach dem Default-Deny-Prinzip, serverseitig anhand des authentifizierten Nutzers, plus Tests, die Cross-Tenant-Zugriff aktiv durchspielen und den Deploy bei Erfolg blockieren.
Was ist der Unterschied zwischen BOLA und BFLA?
BOLA betrifft den Zugriff auf einzelne Objekte, also fremde Daten. BFLA betrifft den Zugriff auf Funktionen oder Aktionen, etwa eine Admin-Funktion. BOLA ist die Objektebene, BFLA die Funktionsebene.