Fehlerhafte Autorisierung auf Funktionsebene (BFLA)

Was ist Fehlerhafte Autorisierung auf Funktionsebene (BFLA)?

Die API bestätigt die Anmeldung eines Aufrufers und führt dann seine angeforderte Funktion aus, ohne die dafür nötige Rolle zu prüfen. Admin-Bedienelemente sind in der Oberfläche ausgeblendet, die Endpunkte prüfen jedoch keine Rolle. So kann jedes gültige Token sie erreichen. Mit einem gültigen Analysten-Token mit Leserechten rufen Sie die vollständige Kundenliste ab und merken eine große Auszahlung vor; beide Anfragen erhalten Status 200. Danach ergänzen Sie am Router die Prüfung authorize('admin') : Sie weist andere Rollen mit Status 403 ab und schützt auch künftige Admin-Routen.

Was Sie lernen in Fehlerhafte Autorisierung auf Funktionsebene (BFLA)

• Eine fehlerhafte Autorisierung auf Funktionsebene erkennen: Eine gültige Sitzung erreicht eine privilegierte Funktion, weil der Endpunkt zwar prüft, wer anfragt, aber nicht, ob dessen Rolle die Funktion aufrufen darf
• Diese Schwachstelle von fehlerhafter Autorisierung auf Objektebene (geänderte Objekt-ID) und einer Rechteausweitung durch Token-Fälschung unterscheiden: Hier bleibt das Token unverändert und hat geringe Rechte; die Funktionsprüfung fehlt.
• Verstehen, dass ein in der Oberfläche ausgeblendetes Admin-Bedienelement oder eine in der Dokumentation weggelassene Route keine Zugriffskontrolle ist, weil Clients die API direkt aufrufen und der Endpunkt trotzdem antwortet
• Die Autorisierung für jede privilegierte Funktion serverseitig durchsetzen. Die Rolle aus der authentifizierten Sitzung statt aus der Anfrage beziehen und die Admin-Routen zentral am Router absichern, damit andere Rollen standardmäßig abgewiesen werden und neue Routen die Prüfung erben.
• Jeden Admin-Endpunkt, jeden internen und jeden nur für Mitarbeiter gedachten Endpunkt daraufhin durchsehen, ob die Rollenprüfung fehlt — besonders dort, wo privilegierte und gewöhnliche Funktionen sich dieselbe authentifizierte API teilen

Fehlerhafte Autorisierung auf Funktionsebene (BFLA) — Trainingsschritte

1. Ein Zugang mit Leserechten

   Fennmark betreibt eine Zahlungsplattform und bietet allen Registrierten Self-Service-Entwicklerkonten an. Bob eröffnet unter einer nur dafür angelegten Identität ein solches Konto. Er erhält die Rolle Analyst mit ausschließlich lesendem Zugriff auf die Sandbox. In der Entwicklerkonsole prüft er, welche Berechtigungen sein Konto hat und welche Funktionen die API anbietet.

2. Admin-Funktionen offen dokumentiert

   Bobs Rolle erlaubt nur lesenden Zugriff. Die Admin-Bedienelemente sind in seiner Oberfläche ausgeblendet. Die API-Referenz zeigt jedoch auch die Funktionen, die nur Mitarbeitende aufrufen dürfen.

3. Was das Token enthält

   Bevor Bob privilegierte Funktionen aufruft, prüft er die Angaben in seinem Token. Im API Tester sendet er eine Anfrage an den Konto-Endpunkt und übergibt sein Session-Token im Authorization-Header — wie die Anwendung selbst.

4. Ein Analyst ohne zusätzliche Rechte

   Der Server bestätigt Bobs Erwartung: Sein Token ist gültig und weist ihn eindeutig als Analysten aus.

5. Eine Admin-Funktion aufrufen

   Bob verwendet dieselbe Anfrage und dasselbe Nur-Lese-Token. Er ändert nur die Ressource in der URL: Statt des Konto-Endpunkts ruft er die vollständige Kundenliste auf, die laut Referenz nur Mitarbeitenden offensteht. Wenn die API lediglich die Gültigkeit der Sitzung prüft, wird sie antworten.

6. Die vollständige Kundenliste für einen Analysten

   Die Admin-Funktion antwortet. Mit seinem Nur-Lese-Token für die Sandbox hat Bob die Kundendatensätze der Plattform abgerufen.

7. Eine Auszahlung veranlassen

   Das Auslesen von Daten ist nur der Anfang. Bob ruft nun einen Endpunkt auf, der eine Auszahlung veranlasst. Er verwendet dasselbe Analysten-Token und gibt ein Konto an, das er kontrolliert.

8. Eine Auszahlung durch ein Sandbox-Konto vorgemerkt

   Auch die Auszahlungsfunktion wurde ausgeführt — ohne Admin-Rolle, Freigabe oder besondere Zugangsdaten.

9. Wissenscheck

10. Die Warnmeldung trifft ein

    Sie verantworten Fennmarks Back-Office-API. Über Nacht meldet das Monitoring ein Self-Service-Entwicklerkonto, das Endpunkte nur für Mitarbeitende aufgerufen hat. Das Security-Operations-Team schickt Ihnen die Details per E-Mail.