Fehlerhafte Autorisierung auf Objektebene (BOLA)

Was ist Fehlerhafte Autorisierung auf Objektebene (BOLA)?

Die fehlerhafte Autorisierung auf Objektebene (BOLA, auch IDOR) ist die häufigste API-Schwachstelle. Ein Endpunkt gibt ein durch eine Anfrage-ID bezeichnetes Objekt aus, ohne zu prüfen, ob es dem Aufrufer gehört. Das Token ist unverändert und gültig. Sie ändern eine Zahl in der URL, lesen einen fremden Fahrtbeleg und rufen weitere fortlaufende IDs ab. Die Korrektur vergleicht den Eigentümer des Datensatzes mit der Identität aus der authentifizierten Sitzung. Fremde und nicht vorhandene IDs erhalten dieselbe 404-Antwort, damit die Existenz eines fremden Datensatzes nicht aus dem Statuscode ablesbar ist.

Was Sie lernen in Fehlerhafte Autorisierung auf Objektebene (BOLA)

• Eine fehlerhafte Autorisierung auf Objektebene erkennen: Eine gültige Sitzung liest das Objekt eines anderen Nutzers, weil der Endpunkt zwar prüft, wer anfragt, aber nicht, ob der ausgelieferte Datensatz dieser Person gehört
• Diese Schwachstelle von fehlerhafter Autorisierung auf Funktionsebene (unerlaubte Funktion) und einer Rechteausweitung durch Token-Fälschung unterscheiden: Hier bleibt das Token unverändert, der Endpunkt darf aufgerufen werden, aber die Objektprüfung fehlt.
• Nachvollziehen, wie fortlaufende oder erratbare Objekt-IDs aus einem einzelnen unbefugten Lesezugriff eine vollständige Enumeration machen — und warum nicht erratbare IDs dieses Risiko zwar senken, aber keine Zugriffskontrolle sind
• Den Fix anwenden: nach dem Laden eines Objekts dessen Eigentümer mit der Identität aus der authentifizierten Sitzung vergleichen — nicht mit irgendetwas, das der Aufrufer mitschickt — und bei Abweichung ablehnen
• Bei einem abgewiesenen Objekt dieselbe 404-Antwort wie bei einer nicht vorhandenen ID bevorzugen. So lässt sich die Existenz fremder Objekte nicht anhand des Statuscodes erkennen. Prüfen Sie alle ID-basierten Lesezugriffe auf diese Lücke.

Fehlerhafte Autorisierung auf Objektebene (BOLA) — Trainingsschritte

1. Ein gewöhnlicher Fahrgast

   Larkway ist eine Fahrdienst-App. Fahrgäste können eine persönliche Trips API aktivieren, um ihre Fahrtbelege für die Reisekostenabrechnung zu exportieren. Bob hat sich unter einer nur dafür angelegten Identität registriert und diese API aktiviert. Sein Konto hat gewöhnliche Fahrgast-Rechte; das Token darf nur seine eigenen Fahrten lesen. In der Entwicklerkonsole prüft Bob die Funktionen der API.

2. Fahrt-IDs sind fortlaufende Zahlen

   Bobs eigene Fahrten stehen mit ihren IDs in der Liste. Die API-Referenz zeigt, wie ein einzelner Fahrtbeleg anhand seiner ID abgerufen wird. An den IDs fallen zwei Dinge auf.

3. Seine eigene Fahrt abrufen

   Bob ruft den Endpunkt zunächst wie vorgesehen auf: Er fragt eine eigene Fahrt anhand ihrer ID ab und übergibt sein Fahrgast-Token im Authorization-Header, genauso wie die App.

4. Seine eigene Fahrt, wie erwartet

   Der Server liefert Bobs eigene Fahrt zurück. Die angefragte ID gehört zu seinem Konto.

5. Eine Zahl ändern

   Bob sendet dieselbe Anfrage mit demselben Token, ändert aber die Fahrt-ID auf die nächstniedrigere Zahl. Prüft der Server die Zuordnung zum Aufrufer, dürfte er keinen fremden Beleg ausliefern. Prüft er nur die Sitzung, wird er antworten.

6. Eine fremde Fahrt

   Der Endpunkt antwortet: Mit seinem eigenen Fahrgast-Token hat Bob einen Beleg abgerufen, der nicht zu seinem Konto gehört.

7. Die IDs durchprobieren

   Bob zählt die IDs weiter herunter. Jede Nummer liefert einen Fahrtbeleg. Mit einer weiteren ID bestätigt er das Muster.

8. Fahrtdaten in großem Umfang

   Die IDs sind fortlaufend und die Anfragen liefern jeweils einen Beleg. Aus dem einzelnen Datenleck wird so ein massenhafter Datenabgriff.

9. Wissenscheck

10. Die Warnmeldung trifft ein

    Sie verantworten Larkways Trips API für Fahrgäste. Über Nacht meldet das Monitoring ein Fahrgast-Token, mit dem Tausende fremde Fahrten abgerufen wurden. Das Security-Operations-Team schickt Ihnen die Details per E-Mail.