IDOR und BOLA

Warum es wichtig ist

IDOR und BOLA stellen die wirkungsvollste Klasse von API-Schwachstellen dar. Broken Object Level Authorization belegt seit ihrer Einführung 2019 die Nummer eins der OWASP API Security Top 10 und hat diese Position im Update 2023 beibehalten.

Der Grund ist einfach: APIs exponieren Objekt-Identifikatoren in URLs, Request-Bodys und Query-Parametern. Wenn der Server nicht verifiziert, dass der anfragende Benutzer das referenzierte Objekt besitzt oder die Berechtigung hat, darauf zuzugreifen, kann jeder authentifizierte Benutzer auf die Daten jedes anderen Benutzers zugreifen, indem er diese Identifikatoren manipuliert.

Reale BOLA-Schwachstellen haben Millionen von Benutzerdatensätzen auf Plattformen von Finanzdienstleistungen bis hin zu sozialen Medien offengelegt. Die Schwachstelle ist besonders gefährlich, weil:

• Sie keine speziellen Werkzeuge oder Fähigkeiten zur Ausnutzung erfordert
• Eine einzige Schwachstelle die Daten jedes Benutzers offenlegen kann
• Sie oft die Verschlüsselung umgeht, da der Angreifer authentifiziert ist
• Automatisierte Ausnutzung gesamte Datenbanken abernten kann

Für Penetrationstester und Bug-Bounty-Jäger ist BOLA/IDOR-Testing eine der ersten Fähigkeiten, die es zu beherrschen gilt, da es die höchste Anzahl valider Befunde im Verhältnis zum Aufwand liefert.

Wie IDOR und BOLA funktionieren

Das Grundmuster

Eine Anwendung weist Objekten Identifikatoren zu: Benutzerprofilen, Bestellungen, Rechnungen, Dateien, Nachrichten oder jeder anderen Ressource. Wenn ein Benutzer ein Objekt anfordert, empfängt die API den Identifikator und gibt die entsprechenden Daten zurück. Die Schwachstelle besteht, wenn die API die Authentifizierung prüft (Ist dieser Benutzer angemeldet?), aber die Autorisierung auslässt (Hat dieser Benutzer die Berechtigung, auf dieses spezifische Objekt zuzugreifen?).

Häufige Identifikatortypen

• Sequenzielle numerische IDs: /api/users/1001 bis /api/users/9999. Leicht aufzuzählen.
• UUIDs: /api/orders/a3f8e2c1-.... Schwerer zu erraten, aber nicht unmöglich, wenn sie in anderen Antworten durchsickern.
• Kodierte Werte: Base64- oder gehashte Identifikatoren, die manchmal dekodiert oder vorhergesagt werden können.
• Zusammengesetzte Schlüssel: /api/org/5/user/12. Mehrere Identifikatoren, die jeweils Autorisierungsprüfungen benötigen.

Testmethodik

1. Erstellen Sie zwei Konten mit unterschiedlichen Rollen oder Eigentümerschaft
2. Erfassen Sie alle API-Anfragen, die Objekt-Identifikatoren enthalten
3. Tauschen Sie Identifikatoren zwischen den Konten aus
4. Testen Sie über alle HTTP-Methoden hinweg (GET zum Lesen, PUT/PATCH zum Aktualisieren, DELETE zum Entfernen)
5. Prüfen Sie sowohl den Antwort-Statuscode als auch den Antwort-Body

Prävention

Die Behebung erfordert serverseitige Autorisierungsprüfungen bei jeder Anfrage, die auf eine benutzerspezifische Ressource zugreift. Der Server muss verifizieren, dass der authentifizierte Benutzer die Berechtigung hat, auf das spezifische in der Anfrage referenzierte Objekt zuzugreifen, und nicht nur, dass ein gültiges Authentifizierungstoken vorhanden ist.

• Implementieren Sie Berechtigungsprüfungen auf Objektebene in API-Middleware oder auf der Datenzugriffsschicht
• Verlassen Sie sich niemals auf Obscurity (UUIDs) als Ersatz für Autorisierung
• Verwenden Sie wo möglich indirekte Referenzen (ordnen Sie sitzungsspezifische Token den tatsächlichen Datenbank-IDs serverseitig zu)
• Protokollieren Sie alle Zugriffsmuster und alarmieren Sie bei horizontalem Zugriff über Benutzergrenzen hinweg