Fehlende Autorisierung auf Funktionsebene (BFLA)
Ein Leitfaden zu Broken Function-Level Authorization (BFLA)
Die Bearbeitung einer API-Anfrage beansprucht Ressourcen: Netzwerkbandbreite, CPU, Arbeitsspeicher, Speicherplatz und manchmal auch kostenpflichtige Dienste von Drittanbietern wie SMS oder biometrische Authentifizierung. Ein uneingeschränkter Ressourcenverbrauch entsteht, wenn eine API nicht begrenzt, wie viel von dieser Ressource eine einzelne Client-Interaktion beansprucht.
Die Risiken, die mit einem uneingeschränkten Ressourcenverbrauch einhergehen, gehen weit über die klassischen Bedenken hinsichtlich Denial-of-Service-Angriffen hinaus. Wenn eine API kostenpflichtige Dienste von Drittanbietern integriert, wird der Ressourcenverbrauch durch fehlende Ausgabenobergrenzen zu einem direkten finanziellen Angriff. Ein einziges automatisiertes Skript, das einen Endpunkt zum Auslösen von SMS-Nachrichten ansteuert, verursacht innerhalb weniger Minuten Kosten in Höhe von Tausenden von Dollar.
GraphQL birgt eine besondere Ausprägung dieses Risikos: Dank seiner Batching-Fähigkeit kann ein Client Hunderte ressourcenintensiver Operationen in einer einzigen Anfrage bündeln, wodurch die für jede einzelne Anfrage geltende API-Ratenbegrenzung umgangen wird.
Wichtigste Erkenntnisse
- „Broken Function Level Authorization“ (BFLA) belegt Platz 5 der OWASP API Security Top 10 2023 und tritt auf, wenn APIs keine Zugriffskontrollen dafür durchsetzen, wer bestimmte Funktionen oder Endpunkte aufrufen darf – und nicht nur, auf welche Objekte der Zugriff möglich ist.
- Im Gegensatz zu BOLA (Objektebene) geht es bei BFLA um den Zugriff auf ganze API-Funktionen oder Endpunkte, die eingeschränkt werden sollten, wie beispielsweise Verwaltungsendpunkte, auf die normale oder anonyme Benutzer zugreifen können.
- Administrative Endpunkte befinden sich häufig neben regulären Endpunkten und nicht unter einem klar abgegrenzten Pfad, sodass sie durch Raten oder durch Analyse der API-Struktur aufgespürt werden können.
- Angreifer können BFLA ausnutzen, indem sie HTTP-Methoden ändern (z. B. von GET zu DELETE), Endpunkt-URLs erraten oder Anforderungsparameter manipulieren, um Funktionen mit erweiterten Berechtigungen auszulösen.
- Zur Prävention ist ein Autorisierungsmodul erforderlich, das standardmäßig den Zugriff verweigert und konsistent auf allen Endpunkten angewendet wird, wobei explizite rollenbasierte Zugriffsberechtigungen und Autorisierungsprüfungen von allen Verwaltungskontrollern übernommen werden.
Warum ist das gefährlich?
BFLA öffnet Angreifern, die es auf Verwaltungsfunktionen abgesehen haben, Tür und Tor. Eine erfolgreiche Ausnutzung führt zu:
- Offenlegung von Daten durch privilegierte Lesevorgänge, die unbefugten Benutzern zugänglich waren
- Datenverlust oder -beschädigung durch privilegierte Schreib- und Löschvorgänge
- Dienstunterbrechung bei Auslösung destruktiver Verwaltungsfunktionen
- Erweiterung von Berechtigungen ohne Diebstahl von Zugangsdaten
Typische Symptome
BFLA tritt in der Regel auf, wenn:
- Administrative Endpunkte haben dieselbe URL-Struktur wie normale Benutzer-Endpunkte, anstatt einen klar abgegrenzten Pfad zu verwenden
- Ändern der HTTP-Methode bei einer Anfrage, z. B. das Umschalten GET zu DELETE, löst privilegierte Funktionen aus
- Das Erraten wahrscheinlicher Endpunktnamen oder -IDs legt Funktionen offen, bei denen keine Autorisierungsprüfung stattfindet
- Die Autorisierungslogik wird nicht zentral, sondern pro Endpunkt implementiert, wodurch Lücken entstehen, wenn ein Entwickler die Überprüfung vergessen hat.
In jedem dieser Fälle läuft es auf dieselbe Lücke hinaus: Die API überprüft zwar die Identität, überprüft jedoch niemals, ob diese Identität zum Aufruf dieser bestimmten Funktion berechtigt ist.
Prävention von BFLA
Eine API sollte standardmäßig den Zugriff verweigern und ihn nur explizit gewähren.
- Wenden Sie ein Autorisierungsmodul mit der Standardregel „Verweigerung“ auf jeden Endpunkt an, unabhängig davon, ob es sich um einen Verwaltungsendpunkt handelt oder nicht.
- Gewähren Sie Zugriff über explizite, rollenbasierte Regeln, anstatt davon auszugehen, dass eine Funktion sicher ist, nur weil sie nicht über die Benutzeroberfläche aufgerufen wird.
- Überprüfen Sie jeden Endpunkt auf Autorisierungsmängel auf Funktionsebene unter Berücksichtigung der Benutzerhierarchie und der Gruppen der Anwendung.
- Stellen Sie sicher, dass jeder Verwaltungs-Controller von einem abstrakten Controller erbt, der rollenbasierte Autorisierungsprüfungen durchführt.
- Implementieren Sie dieselben rollenbasierten Prüfungen für Verwaltungsfunktionen, die in einem regulären, nicht-administrativen Controller enthalten sind.
Eine Verwaltungsfunktion zu verbergen ist nicht dasselbe wie sie zu schützen. Solange der Endpunkt existiert, wird ein Angreifer ihn früher oder später finden.
