Fehlerhafte Autorisierung auf Objektebene (BOLA)

Was ist Fehlerhafte Autorisierung auf Objektebene (BOLA)?

Eine fehlerhafte Autorisierung auf Objektebene, auch BOLA oder IDOR genannt, ist die häufigste API-Schwachstelle. Der Endpunkt gibt das durch einen Bezeichner in der Anfrage benannte Objekt zurück, ohne zu prüfen, ob es zum Aufrufer gehört. Das Zeichen ist ehrlich. Sie ändern eine einzelne Zahl in einer By-ID-URL, lesen den Datensatz eines Fremden und führen dann sequentielle Identifikatoren in eine Massensammlung ein. Der Fix vergleicht den Eigentümer des Datensatzes mit der authentifizierten Sitzung und gibt 404 statt 403 zurück, sodass das Vorhandensein einer abgelehnten ID nicht bestätigt werden kann.

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 der fehlerhaften Autorisierung auf Funktionsebene (eine Rolle erreicht eine Funktion, die sie nicht aufrufen darf) und von einer Rechteausweitung durch Token-Fälschung (Manipulation der eigenen Zugangsdaten) unterscheiden; hier ist das Token ehrlich, der Endpunkt freigegeben, und es fehlt die Objektprüfung
• 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 eine Not-Found- statt einer Forbidden-Antwort bevorzugen, damit eine abgelehnte ID von einer fehlenden nicht zu unterscheiden ist und das Existenz-Orakel geschlossen wird — und jeden ID-basierten Lesezugriff auf dieselbe Lücke prüfen

Fehlerhafte Autorisierung auf Objektebene (BOLA) — Trainingsschritte

1. Ein ganz normaler Fahrgast

   Larkway ist eine Fahrdienst-App, und jeder Fahrgast kann sich dort eine persönliche Trips API freischalten, um die eigenen Fahrtbelege für die Reisekostenabrechnung zu exportieren. Bob hat sich mit einer Wegwerf-Identität als ganz normaler Fahrgast registriert und die Schnittstelle aktiviert. Sein Konto ist nichts Besonderes: ein einfacher Fahrgast-Zugang mit einem Token, das seine eigenen Fahrten lesen darf. Er öffnet die Entwicklerkonsole, um zu sehen, was die API ihm liefert.

2. Fahrt-IDs: einfach nur Zahlen

   Bobs eigene Fahrten stehen samt ihrer IDs in der Liste, und die API-Referenz zeigt, wie sich jeder einzelne Fahrtbeleg über seine ID abrufen lässt. An diesen IDs fallen zwei Dinge auf.

3. Die eigene Fahrt abrufen

   Zuerst ruft Bob den Endpunkt genau so auf, wie er gedacht ist: Er fragt eine seiner eigenen Fahrten über deren ID ab und schickt dabei sein eigenes Fahrgast-Token im Authorization-Header mit — exakt so, wie es auch die App tut.

4. Seine Fahrt, wie erwartet

   Der Server liefert genau das, was er soll: Bobs eigene Fahrt — denn die ID, nach der er gefragt hat, gehört ihm.

5. Eine Zahl ändern

   Bob schickt dieselbe Anfrage mit demselben Token und ändert nur die ID — eine Nummer unter seiner eigenen. Prüft der Server, ob eine Fahrt dem Aufrufer gehört, darf nichts zurückkommen. Prüft er nur, ob die Sitzung gültig ist, antwortet er.

6. Eine fremde Fahrt

   Er antwortet. Bobs eigenes Fahrgast-Token hat gerade eine Fahrt abgerufen, die nicht das Geringste mit ihm zu tun hat.

7. Die Reihe durchzählen

   Ein einzelner Fremder ist noch eine Kuriosität. Bob zählt die ID weiter herunter, und jeder Wert liefert einen echten Beleg. Er greift sich noch einen, um das Muster zu bestätigen.

8. Jeder Fahrgast, in großem Stil

   Die IDs laufen lückenlos durch, und jede einzelne antwortet. Aus einem einzelnen Datenleck wird damit ein Massenabgriff.

9. Wissenscheck

   Sie haben gerade gesehen, wie ein gültiger Fahrgast fremde Fahrten liest, indem er die ID in der URL ändert. Prägen Sie sich ein, warum das funktioniert.

10. Der Alarm trifft ein

    Sie verantworten Larkways Trips API für Fahrgäste. Über Nacht ist dem Monitoring ein einzelnes Fahrgast-Token aufgefallen, das Tausende fremder Fahrten abgerufen hat. Security Operations hat Ihnen die Details per E-Mail geschickt.