Broken Object Level Authorization

Wenn du dich bei einem Onlineshop einloggst und deine Rechnung ansiehst, schickt dein Browser eine Anfrage an den Server des Shops. In dieser Anfrage steht oft eine Nummer, zum Beispiel « Rechnung 5012 ». Der Server soll nun zwei Dinge prüfen: Bist du wirklich eingeloggt, und gehört dir diese Rechnung überhaupt? Broken Object Level Authorization bezeichnet den Fehler, dass nur die erste Prüfung stattfindet und die zweite fehlt. Ändert man die Nummer von Hand auf 5013, liefert der Server die Rechnung eines fremden Kunden aus. Der englische Name bedeutet sinngemäß: Die Rechtekontrolle für einzelne Datensätze ist kaputt.

Warum eine falsche Nummer ganze Datenbanken leert

Diese Lücke steht seit Jahren auf Platz eins der bekanntesten Fehlerliste für Programmierschnittstellen, der OWASP API Security Top 10. OWASP ist eine gemeinnützige Organisation, die Sicherheitsprobleme in Software sammelt und bewertet. Der Grund für den Spitzenplatz ist einfach: Der Fehler ist häufig, leicht zu finden und richtet großen Schaden an.

Besonders unangenehm ist, dass für den Angriff keine besonderen Werkzeuge nötig sind. Es braucht kein Passwort-Knacken und keinen Schadcode. Ein normaler Nutzerzugang genügt, dazu die Bereitschaft, in der Adresszeile eine Zahl hochzuzählen. Wer das automatisiert, lädt in wenigen Stunden hunderttausende Datensätze herunter.

In der Praxis sind so schon Kontostände, Krankenakten, Ausweisfotos und Chatverläufe abgeflossen. Für Unternehmen ist das nicht nur ein Imageschaden. In der EU können nach der Datenschutz-Grundverordnung Bußgeldern in Millionenhöhe folgen, wenn personenbezogene Daten unzureichend geschützt waren.

Identität prüfen ist nicht dasselbe wie Berechtigung prüfen

Software unterscheidet zwei Schritte. Die Authentifizierung klärt, wer du bist, meist über Login und Passwort. Die Autorisierung klärt, was du sehen und ändern darfst. Bei dieser Lücke funktioniert Schritt eins tadellos, Schritt zwei wird für einzelne Objekte schlicht vergessen.

Ein Vergleich macht das greifbar. Ein Hotel prüft an der Rezeption deinen Ausweis und lässt dich hinein. Wenn danach aber jede Zimmertür mit demselben Schlüssel aufgeht, nützt die Ausweiskontrolle wenig. Genau so verhält sich ein Server, der nur den Login prüft und danach jeden Datensatz herausgibt.

Vorbeugen lässt sich das durch eine Regel im Code: Vor jeder Ausgabe eines Datensatzes wird geprüft, ob er zum angemeldeten Konto gehört. Zusätzlich helfen schwer zu erratende Kennungen, etwa lange Zufallszeichenfolgen statt fortlaufender Nummern. Das allein ist aber keine Lösung, sondern nur eine Erschwernis. Sicherheit durch Verstecken gilt als Irrtum, weil solche Kennungen über Links, Protokolldateien oder andere Nutzer trotzdem bekannt werden.

Von der Banking-App bis zum KI-Assistenten

Betroffen sind vor allem Anwendungen, die Daten über eine Schnittstelle nachladen, statt komplette Seiten zu liefern. Das trifft auf fast jede moderne Handy-App zu, ebenso auf Webportale von Banken, Behörden und Kliniken. In Sicherheitsmeldungen taucht der Fehler auch unter dem älteren Namen Insecure Direct Object Reference auf, kurz IDOR. Gemeint ist im Kern dasselbe.

In den Nachrichten begegnet dir der Begriff meist nach einem Datenleck. Wenn es heißt, Kundendaten seien « ohne Hackerangriff frei abrufbar » gewesen, steckt oft genau diese Lücke dahinter. Unternehmen zahlen inzwischen Prämien an Sicherheitsforscher, die solche Fehler melden. Solche Bug-Bounty-Programme sind billiger als ein Leck mit Schlagzeilen.

Neue Bedeutung bekommt das Thema durch KI-Assistenten, die im Auftrag von Nutzern selbstständig Schnittstellen abfragen. Ein solcher Assistent probiert Anfragen in hoher Zahl und ohne Zögern aus. Fehlt die Berechtigungsprüfung, kann er unbeabsichtigt fremde Daten in eine Antwort holen. Deshalb gehört die Kontrolle auf Objektebene zu den Punkten, die bei KI-Produkten früh geprüft werden sollten.