Broken Object Property Level Authorization (BOPLA)

Wie der Angriff funktioniert

APIs geben tendenziell alle Eigenschaften eines Objekts zurück (besonders bei REST) oder akzeptieren ganze Objekt-Payloads, ohne pro Eigenschaft eine Autorisierungsprüfung durchzuführen.

Es gibt zwei Ausprägungen:

1. Lesen - die API liefert in der Antwort sensible Properties mit, die der Nutzer nicht sehen dürfte (früher "Excessive Data Exposure").
2. Schreiben - die API bindet die Client-Eingabe automatisch an interne Objekt-Eigenschaften (z. B. via Mass Assignment / Auto-Binding), sodass ein Angreifer sensible Felder setzen, ändern oder hinzufügen kann, auf die er keinen Zugriff haben sollte (früher "Mass Assignment").

Laut OWASP genügt das Inspizieren der API-Antworten, um sensible Informationen in den zurückgegebenen Objekt-Darstellungen zu identifizieren; Fuzzing wird typischerweise genutzt, um zusätzliche (versteckte) Properties zu finden.

Ob diese verändert werden können, ist eine Frage des Erstellens eines manipulierten Requests und der Analyse der Antwort. Ist die Ziel-Property nicht in der Antwort enthalten, kann eine Seiteneffekt-Analyse nötig sein.

Beispiel

Schreibender Angriff (OWASP-Szenario #3, Kurzvideo-Plattform mit Zensur): Ein Nutzer darf legitim die Beschreibung seines Videos ändern - auch wenn das Video bereits gesperrt ist.

1. Legitimer Request: PUT /api/video/update_video mit { "description": "a funny video about cats" }
2. Der frustrierte Nutzer wiederholt den Request und fügt eine zusätzliche, interne Eigenschaft hinzu: PUT /api/video/update_video mit { "description": "a funny video about cats", "blocked": false }
3. Da die API nicht prüft, ob der Nutzer die interne Eigenschaft blocked verändern darf, wird der Wert von true auf false gesetzt - der Nutzer hebt damit die Sperre seines eigenen, eigentlich blockierten Inhalts auf.

Wortlaut und Payloads exakt wie auf der OWASP-Seite.

Auswirkung

Unbefugter Zugriff auf private/sensible Objekt-Eigenschaften kann zu Datenoffenlegung (data disclosure), Datenverlust (data loss) oder Datenbeschädigung (data corruption) führen.

Unter bestimmten Umständen kann unbefugter Zugriff auf Objekt-Eigenschaften zu Rechteausweitung (Privilege Escalation) oder zur teilweisen bzw. vollständigen Kontoübernahme (Account Takeover) führen.

Geschäftlich konkret laut OWASP-Szenarien:

• Szenario #1 - fremde sensible Daten wie fullName und recentLocation werden offengelegt.
• Szenario #2 - ein Gast wird über das interne Feld total_stay_price übermäßig belastet, da der angreifende Host diesen Preis manipuliert.
• Szenario #3 - gesperrte Inhalte werden über das Feld blocked wieder freigeschaltet.

So schützt man sich

• Beim Bereitstellen eines Objekts über einen API-Endpunkt immer sicherstellen, dass der Nutzer tatsächlich auf die zurückgegebenen Eigenschaften zugreifen darf.
• Generische Methoden wie to_json() und to_string() vermeiden; stattdessen gezielt nur die Eigenschaften auswählen ('cherry-picking'), die wirklich zurückgegeben werden sollen.
• Wenn möglich keine Funktionen verwenden, die Client-Eingaben automatisch an Code-Variablen, interne Objekte oder Objekt-Eigenschaften binden ('Mass Assignment').
• Änderungen nur an genau den Objekt-Eigenschaften zulassen, die der Client tatsächlich aktualisieren darf.
• Als zusätzliche Sicherheitsschicht eine schemabasierte Validierung der Antworten implementieren: die von allen API-Methoden zurückgegebenen Daten definieren und erzwingen.
• Zurückgegebene Datenstrukturen auf das fachlich/funktional notwendige Minimum beschränken.

Quellen

• API3:2023 Broken Object Property Level Authorization - OWASP API Security Top 10 2023 OWASP API Security Project, 2023