Broken Function Level Authorization (BFLA)

Wie der Angriff funktioniert

Berechtigungsprüfungen für eine Funktion oder Ressource werden meist über Konfiguration oder im Code umgesetzt. Das korrekt zu tun ist fehleranfällig, weil moderne Anwendungen viele Rollen, Gruppen und komplexe Nutzerhierarchien haben (z. B. Sub-Nutzer oder Nutzer mit mehreren Rollen).

Während die Authentifizierung klärt "wer bin ich", muss die Funktionsebenen-Autorisierung klären "darf ich diese Aktion ausführen" - genau diese Prüfung fehlt bei BFLA an einzelnen Endpunkten. Da APIs strukturiert und der Zugriff auf verschiedene Funktionen vorhersehbar aufgebaut ist, lassen sich solche Lücken leichter entdecken und ausnutzen.

Prüfende Fragen laut OWASP:

• Administrative Endpunkte: Kann ein regulärer Nutzer administrative Endpunkte erreichen?
• HTTP-Methode wechseln: Kann ein Nutzer sensible Aktionen (Anlegen, Ändern, Löschen) auslösen, indem er einfach die HTTP-Methode wechselt (z. B. von GET zu DELETE)?
• Fremde Gruppenfunktion: Kann ein Nutzer aus Gruppe X eine Funktion erreichen, die nur Gruppe Y zusteht, indem er Endpunkt-URL und Parameter errät (z. B. /api/v1/users/export_all)?

Ein Trugschluss ist, einen Endpunkt allein anhand des URL-Pfads als "regulär" oder "administrativ" einzustufen: Administrative Endpunkte liegen häufig nicht nur unter /api/admins, sondern auch zusammen mit regulären unter /api/users.

Beispiel

OWASP-Szenario 1 (Einladungssystem mit erzwungener Admin-Rolle):

1. Eine Anwendung erlaubt nur eingeladene Nutzer. Während der Registrierung ruft die Mobile-App GET /api/invites/{invite_guid} auf. Die Antwort enthält ein JSON mit Einladungsdetails, inkl. Rolle und E-Mail des Nutzers.
2. Der Angreifer dupliziert die Anfrage und manipuliert HTTP-Methode und Endpunkt zu POST /api/invites/new. Dieser Endpunkt sollte nur Administratoren über die Admin-Konsole zur Verfügung stehen und implementiert keine Funktionsebenen-Autorisierung.
3. Der Angreifer sendet eine neue Einladung mit Admin-Rechten: POST /api/invites/new { "email": "attacker@somehost.com", "role": "admin" }
4. Später nutzt der Angreifer die manipuliert erstellte Einladung, um sich ein Admin-Konto anzulegen, und erhält vollen Zugriff auf das System.

Auswirkung

Solche Lücken erlauben Angreifern den Zugriff auf nicht autorisierte Funktionalität. Administrative Funktionen sind Hauptziele und können zu Datenoffenlegung, Datenverlust oder Datenkorruption führen; letztlich kann dies zu einer Dienstunterbrechung (Service-Ausfall) führen.

Im OWASP-Beispiel verschafft sich der Angreifer dadurch vollständigen Admin-Zugriff auf das gesamte System - geschäftlich also potenzieller Kontrollverlust über die Anwendung und ihre Nutzerdaten. Der Business Impact ist laut OWASP anwendungsspezifisch.

So schützt man sich

• Konsistentes, leicht analysierbares Autorisierungsmodul bereitstellen, das aus allen Geschäftsfunktionen heraus aufgerufen wird; häufig liegt dieser Schutz in einer oder mehreren Komponenten außerhalb des Anwendungscodes.
• Deny-all als Standard: Der Durchsetzungsmechanismus muss jeden Zugriff per Default verweigern und explizite Freigaben für bestimmte Rollen je Funktion erfordern.
• API-Endpunkte gezielt auf Funktionsebenen-Autorisierungsfehler prüfen - unter Berücksichtigung der Geschäftslogik und der Gruppenhierarchie.
• Sicherstellen, dass alle administrativen Controller von einem abstrakten Admin-Controller erben, der Autorisierungsprüfungen anhand Gruppe/Rolle des Nutzers implementiert.
• Sicherstellen, dass administrative Funktionen innerhalb regulärer Controller Autorisierungsprüfungen anhand Gruppe und Rolle des Nutzers implementieren.

Quellen

• API5:2023 Broken Function Level Authorization - OWASP API Security Top 10 2023 OWASP API Security Project, 2023