Was ist IDOR / BOLA?

IDOR / BOLA einfach erklärt

IDOR steht für Insecure Direct Object Reference, auf Deutsch etwa „unsicherer direkter Verweis auf ein Objekt“. BOLA steht für Broken Object Level Authorization, also eine „fehlerhafte Berechtigungsprüfung auf Objektebene“. Beide Begriffe beschreiben dasselbe Problem. Eine Webanwendung oder eine Programmierschnittstelle (API) gibt Datensätze wie Rechnungen, Bestellungen oder Profile anhand einer Kennung heraus. Dabei prüft sie nicht, ob die anfragende Person diesen Datensatz überhaupt sehen darf.

Ein Vergleich: An der Theatergarderobe bekommen Sie gegen Ihre Marke mit der Nummer 57 Ihren Mantel. Sagen Sie stattdessen „Nummer 58“, reicht man Ihnen ohne Nachfrage den Mantel einer fremden Person. Die Garderobe prüft nur die Nummer – nicht, ob sie zu Ihnen gehört.

So funktioniert ein IDOR-Angriff

1. Der Angreifer nutzt ein ganz normales Konto, etwa als Kunde eines Onlineshops.
2. Er beobachtet die Anfragen, die sein Browser oder seine App an den Server schickt, zum Beispiel den Abruf „/api/rechnungen/1001“.
3. Er ändert die Kennung auf 1002, 1003 und so weiter.
4. Prüft der Server nur, ob jemand angemeldet ist, aber nicht, ob die Rechnung zu diesem Konto gehört, liefert er fremde Daten aus. Mit einem einfachen Skript lassen sich so in kurzer Zeit große Datenmengen abrufen.

Je nach Funktion kann ein Angreifer fremde Daten nicht nur lesen, sondern auch ändern oder löschen. Zufällig aussehende Kennungen erschweren das Raten, lösen das Problem aber nicht: Sie tauchen etwa in Links, Protokollen oder anderen Antworten der Anwendung auf.

Automatische Scanner übersehen die Lücke häufig. Sie können nicht wissen, welche Rechnung zu welchem Konto gehört – eine Antwort mit fremden Daten sieht für sie völlig normal aus. In den OWASP API Security Top 10, einer weltweit genutzten Liste der wichtigsten API-Risiken, steht BOLA auf Platz 1. Bei Webanwendungen gehört IDOR zur Kategorie „Broken Access Control“ (fehlerhafte Zugriffskontrolle), die auch in der aktuellen Ausgabe der OWASP Top 10 auf Platz 1 steht.

Ein Beispiel aus der Praxis

Eine Hausverwaltung bietet Mieterinnen und Mietern eine App, in der sie Schäden melden und Nebenkostenabrechnungen herunterladen. Im API-Penetrationstest arbeitet das Prüfteam mit zwei Testkonten und stellt fest: Die Schnittstelle für den Download prüft nur, ob jemand angemeldet ist. Mit der Nummer einer fremden Abrechnung lässt sich diese abrufen – samt Name, Anschrift und Bankverbindung.

Die App selbst bietet diese Möglichkeit nie an; der Fehler steckt allein in der Schnittstelle. Das Team meldet den kritischen Befund sofort, und die Entwicklung ergänzt eine zentrale Prüfung, die bei jedem Abruf die Zuordnung zum angemeldeten Konto kontrolliert.

Warum ist das für Unternehmen wichtig?

IDOR-Lücken sind leicht auszunutzen und betreffen oft sensible Daten. Gelangen personenbezogene Daten an Unbefugte, liegt in der Regel eine Datenschutzverletzung nach der DSGVO vor. Diese ist unverzüglich und möglichst binnen 72 Stunden der Aufsichtsbehörde zu melden. Eine Ausnahme gilt nur, wenn die Verletzung voraussichtlich zu keinem Risiko für die Betroffenen führt.

Besonders heikel ist die Lücke bei Plattformen, die viele Kundenfirmen gemeinsam nutzen. Sieht ein Kunde die Daten eines anderen, steht schnell das Vertrauen in die ganze Plattform auf dem Spiel. Moderne Web- und Mobile-Apps hängen zudem stark von APIs ab, die Kennungen direkt verarbeiten. Technisch ist IDOR meist eine Form der horizontalen Privilege Escalation: Ein Konto greift auf Daten eines gleichrangigen Kontos zu.

So schützen Sie sich

• Bei jedem Zugriff prüfen: Kontrollieren Sie serverseitig bei jedem Abruf, jeder Änderung und jedem Löschen, ob das angemeldete Konto den Datensatz verwenden darf.
• Zentral regeln: Bündeln Sie die Berechtigungslogik an einer Stelle, statt sie in jeder Funktion neu zu programmieren. Grundsatz: Zugriff verweigern, solange er nicht ausdrücklich erlaubt ist.
• Kennungen nicht als Schutz verstehen: Zufällige IDs sind sinnvoll, ersetzen aber keine Berechtigungsprüfung.
• Automatisiert testen: Ergänzen Sie Ihre automatischen Tests um Fälle, in denen ein zweites Konto gezielt auf fremde Datensätze zugreifen will.
• Auffälligkeiten erkennen: Protokollieren Sie auffällig viele Abrufe aufeinanderfolgender Kennungen und begrenzen Sie die Zahl der Anfragen.
• Manuell testen lassen: Ein Penetrationstest mit mehreren Konten pro Rolle deckt solche Fehler gezielt auf – typischerweise als Grey-Box-Test.

Wie Rootsektor unterstützt

Im API-Penetrationstest prüfen wir Ihre Schnittstellen systematisch mit mehreren Konten pro Rolle – auch zwischen verschiedenen Kundenfirmen auf derselben Plattform. Dabei orientieren wir uns an den OWASP API Security Top 10. Webanwendungen mit Login testen wir im Penetrationstest für Webanwendungen & Webshops. Kritische Schwachstellen melden wir sofort – noch während des Tests, telefonisch oder per E-Mail an die vereinbarte Ansprechperson. Ein Festpreisangebot nach dem Scoping erhalten Sie über unser Pentest-Angebot.