Berechtigungsebene für beschädigte Objekte (BOLPA)
Ein Leitfaden zu die Autorisierung auf Objektebene für beschädigte Objekte (BOLPA)
Die „Broken Object Property Level Authorization“ (BOPLA) fasst zwei Risiken aus der Liste von 2019 zusammen: übermäßige Datenoffenlegung und Massenzuordnung, zu einer einzigen Kategorie zusammen, die auf einer gemeinsamen Ursache basiert: fehlende oder unsachgemäße Berechtigungsprüfungen auf Objektebene.
BOPLA tritt in zwei Formen auf. Die eine ist die Offenlegung von Daten, bei der eine API mehr Eigenschaften zurückgibt, als ein bestimmter Benutzer sehen sollte. Die andere ist die Massenzuweisung, bei der eine API vom Client bereitgestellte Werte für Eigenschaften akzeptiert, die ein Benutzer eigentlich nicht ändern dürfen sollte. Beide Formen sind auf dieselbe Lücke zurückzuführen: Die API überprüft zwar den Zugriff auf das Objekt als Ganzes, nicht jedoch auf dessen einzelne Felder.
Da Objekteigenschaften direkt in API-Antworten sichtbar sind, lässt sich diese Sicherheitslücke von Angreifern leicht aufspüren. Bei der Überprüfung einer Antwort werden offengelegte Felder sichtbar. Durch Fuzzing der Anfrage-Payloads werden versteckte, beschreibbare Felder aufgedeckt.
Wichtigste Erkenntnisse
- „Broken Object Property Level Authorization“ (BOPLA) belegt Platz 3 der OWASP API Security Top 10 2023 und fasst zwei zuvor getrennte Risiken zusammen: übermäßige Datenoffenlegung und Massenzuweisung.
- Die Sicherheitslücke hat zwei unterschiedliche Ausprägungen: APIs, die mehr Objekteigenschaften zurückgeben, als der Benutzer sehen sollte (Datenoffenlegung), und APIs, die es Benutzern ermöglichen, Eigenschaften zu ändern, auf die sie keinen Zugriff haben sollten (Massenzuweisung)
- Die Schwachstelle lässt sich leicht ausnutzen: Bei der Überprüfung der API-Antworten werden sensible Eigenschaften sichtbar, während durch Fuzzing versteckte Eigenschaften aufgedeckt werden können, die möglicherweise ebenfalls beschreibbar sind.
- Die Auswirkungen in der Praxis reichen von der Offenlegung sensibler Daten über die Ausweitung von Berechtigungen bis hin zu finanziellen Manipulationen, wie Szenarien zeigen, in denen beispielsweise einem Gast durch die Änderung einer Preiseigenschaft ein zu hoher Betrag in Rechnung gestellt wird.
- Zur Vermeidung von Sicherheitslücken sollten bestimmte Eigenschaften gezielt zur Rückgabe ausgewählt werden, anstatt generische Serialisierungsmethoden zu verwenden; außerdem sollte eine schemabasierte Validierung der Antworten implementiert und streng festgelegt werden, welche Eigenschaften ein Client ändern darf.
Warum ist das gefährlich?
Die Auswirkungen von BOPLA in der Praxis reichen von der Offenlegung bis hin zu direkter Finanzmanipulation. Zu den Folgen zählen:
- Offenlegung sensibler Eigenschaften, die niemals für den Kunden bestimmt waren, wie z. B. interne Kennzeichen oder personenbezogene Daten
- Erweiterung von Berechtigungen durch Änderung von Rollen- oder Berechtigungsfeldern
- Finanzmanipulationen, wie beispielsweise wenn ein Host einen „total_stay_price“ in eine Buchungsanfrage einfügt, um einem Gast einen überhöhten Preis in Rechnung zu stellen
- Nachgelagerte Vertrauensverletzungen, wenn offengelegte Eigenschaften in andere Systeme einfließen
Typische Symptome
BOPLA tritt in der Regel auf, wenn:
- Ein Endpunkt verwendet eine generische Serialisierungsmethode wie to_json() und gibt das gesamte Objekt zurück
- A PATCH oder PUT -Anfrage akzeptiert jedes Feld in der Nutzlast und schreibt es ohne Zulassungsliste in die Datenbank
- Interne Statusfelder, wie beispielsweise is_admin oder blocked, sind für den Client sowohl lesbar als auch beschreibbar
- Antwortschemata sind nicht dokumentiert, sodass niemand bemerkt, wenn ein neues sensibles Feld in die Ausgabe gelangt
Der gemeinsame Nenner: Das Objekt ist autorisiert, seine Eigenschaften jedoch nicht.
Prävention BOPLA
Die Überprüfung auf Eigenschaftenebene muss explizit erfolgen und darf nicht aus Überprüfungen auf Objektebene abgeleitet werden.
- Stellen Sie sicher, dass der Benutzer Zugriff auf alle Eigenschaften hat, die ein Endpunkt bereitstellt, bevor Sie diesen zurückgeben.
- Legen Sie die Eigenschaften fest, die ein Endpunkt zurückgibt, anstatt das gesamte Objekt mit generischen Methoden zu serialisieren.
- Vermeiden Sie Funktionen, die Benutzereingaben automatisch an Codevariablen, interne Objekte oder Objekteigenschaften binden.
- Änderungen nur an den spezifischen Eigenschaften zulassen, die ein Client aktualisieren können soll
- Wenden Sie eine schemabasierte Validierung der Antworten an, um unbeabsichtigte Felder zu erkennen, bevor sie versendet werden
- Beschränken Sie die zurückgegebenen Datenstrukturen auf das absolute Minimum, das die geschäftlichen Anforderungen des Endpunkts erfordern.
Ein Benutzer, der für ein Objekt berechtigt ist, sollte nicht automatisch alle dessen Eigenschaften einsehen oder bearbeiten können.
