Fehlerhafte Autorisierung auf Funktionsebene (BFLA)

Was ist Fehlerhafte Autorisierung auf Funktionsebene (BFLA)?

Eine API bestätigt, dass ein Anrufer angemeldet ist, und führt dann die gewünschte Funktion aus, ohne zu prüfen, ob ihre Rolle sie aufrufen darf. Privilegierte Kontrollen werden in der Schnittstelle ausgeblendet, während die Endpunkte selbst keiner Rollenprüfung unterliegen, sodass jedes gültige Token sie erreicht. Sie verwenden einen ehrlichen, schreibgeschützten Analysten-Token, um eine vollständige Kundenliste abzurufen und eine große Auszahlung in die Warteschlange zu stellen, wobei jede Anfrage mit 200 beantwortet wird. Anschließend versenden Sie einen authorize('admin') -Guard auf Router-Ebene, der 403 zurückgibt, sodass die Admin-Oberfläche standardmäßig abgelehnt wird und neue Routen die Prüfung erben.

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 der fehlerhaften Autorisierung auf Objektebene (geänderte Objekt-ID) und von einer Rechteausweitung durch Token-Fälschung (Manipulation der eigenen Zugangsdaten) unterscheiden; hier ist das Token ehrlich und mit niedrigen Rechten ausgestattet, und es fehlt die Prüfung an der Funktion
• 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
• Den Fix anwenden: die Autorisierung serverseitig an jeder privilegierten Funktion durchsetzen, die Rolle des Aufrufers aus der authentifizierten Sitzung statt aus der Anfrage nehmen und an der Router-Grenze eine Prüfung bevorzugen, die standardmäßig sperrt, damit neue Routen sie 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 Nur-Lese-Zugang

   Fennmark betreibt eine Zahlungsplattform und gibt jedem, der sich registriert, ein Self-Service-Entwicklerkonto. Bob hat sich eines geholt — mit einer Wegwerf-Identität. Sein Zugang ist der eines Analysten: nur lesend, auf die Sandbox beschränkt, nichts Sensibles. Er öffnet die Entwicklerkonsole, um sich einen Überblick zu verschaffen: was sein Konto ist und was die API zu bieten hat.

2. Admin-Funktionen, offen sichtbar

   Weil Bobs Zugang nur lesen darf, blendet die Oberfläche die Admin-Steuerelemente für ihn aus. Die API-Referenz blendet nichts aus: Dort steht jede Funktion, die nur Mitarbeitern offensteht, direkt neben denen, die er aufrufen darf.

3. Was im Token steht

   Bevor er irgendetwas Privilegiertes anfasst, sieht Bob nach, welche Identität sein eigenes Token mitführt. Er richtet den API Tester auf den Konto-Endpunkt und schickt sein Session-Token im Authorization-Header mit — genau so, wie es auch die App tut.

4. Ein ehrlicher Analyst

   Der Server bestätigt genau das, was Bob erwartet hat. Sein Token ist echt, und es sagt unumwunden, was er ist.

5. Eine Admin-Funktion aufrufen

   Bob behält dieselbe Anfrage und dasselbe Nur-Lese-Token bei und tauscht in der URL nur die Ressource — gegen eine Funktion, die die Referenz als „nur für Mitarbeiter“ ausweist: die vollständige Kundenliste. Prüft die API bloß, ob seine Sitzung gültig ist, und nie seine Rolle, dann antwortet sie.

6. Die komplette Kundenliste — für einen Analysten

   Die Admin-Funktion hat geantwortet. Bobs Nur-Lese-Token aus der Sandbox hat gerade die Kundendatensätze der Plattform abgerufen.

7. Geld bewegen

   Daten lesen ist das eine. Jetzt ruft Bob eine Funktion auf, die den Zustand verändert: den Auszahlungs-Endpunkt, der eine Auszahlung vormerkt. Er schickt die Anfrage mit demselben Analysten-Token und trägt als Ziel ein Konto ein, über das er selbst verfügt.

8. Eine Auszahlung, vorgemerkt von einem Sandbox-Konto

   Auch die Funktion, die Geld bewegt, ist durchgelaufen. Kein Admin, keine Freigabe, keine besonderen Zugangsdaten.

9. Wissenscheck

   Sie haben gerade gesehen, wie ein Nur-Lese-Konto die Kundenliste ausliest und eine Auszahlung vormerkt. Prägen Sie sich ein, warum das funktioniert.

10. Der Alarm trifft ein

    Sie verantworten Fennmarks Back-Office-API. Über Nacht ist dem Monitoring ein Self-Service-Entwicklerkonto aufgefallen, das Endpunkte aufgerufen hat, die nur Mitarbeitern offenstehen. Security Operations hat Ihnen die Details per E-Mail geschickt.