Broken Object Level Authorization in the Wild: An Empirical Taxonomy from 100+ Bug Bounty Disclosures
Dieser Beitrag stellt eine groß angelegte empirische Analyse von 107 klassifizierten Bug-Bounty-Berichten vor, die zeigt, dass Action-Level-Object-BOLA eine dominante, jedoch unterrepräsentierte Schwachstellenfamilie darstellt, und belegt, dass die Abhängigkeit von Plattform-Tags die Verbreitung von Broken Object Level Authorization erheblich überschätzt.
Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen
Stellen Sie sich vor, Sie gehen durch einen riesigen, hochtechnologischen Wohnkomplex. Sie besitzen eine Schlüsselkarte, die Ihnen den Zutritt zum Gebäude ermöglicht (Authentifizierung), aber die eigentliche Sicherheit sollte darin bestehen, zu prüfen, welche spezifische Wohnung Sie betreten dürfen.
Broken Object Level Authorization (BOLA) tritt ein, wenn der Sicherheitsbeamte des Gebäudes vergisst, Ihre Schlüsselkarte mit der spezifischen Wohnungsnummer abzugleichen, die Sie öffnen möchten. Sie mögen zwar ein gültiger Bewohner sein, aber Sie versuchen, Wohnung 402 zu öffnen, und der Beamte sagt einfach: „Klar, gehen Sie vor", ohne zu prüfen, ob 402 Ihnen gehört.
Dieses Papier ist eine umfassende Untersuchung von 107 realen Sicherheitsberichten aus einem Bug-Bounty-Programm (bei dem Hacker bezahlt werden, um diese Lücken zu finden). Die Forscher wollten über „theoretische" Sicherheitsempfehlungen hinausgehen und untersuchen, was in der realen Welt tatsächlich passiert.
Hier ist die Aufschlüsselung ihrer Erkenntnisse, unter Verwendung einfacher Analogien:
1. Das Problem der „Label Noise" (Die falschen Alarme)
Die Forscher begannen damit, 200 Berichte zu untersuchen, die auf HackerOne als „IDOR" (ein gängiger Name für diese Art von Fehler) gekennzeichnet waren.
- Die Erkenntnis: Nur 42 % dieser Berichte waren tatsächlich der echte Fall.
- Die Analogie: Stellen Sie sich eine Feueralarmanlage vor, die 200 Mal auslöst. Die Forscher stellten fest, dass in 39 % der Fälle gar kein Brand vorlag – es war nur jemand, der Toast verbrannte, eine dampfende Dusche oder ein defekter Sensor.
- Fazit: Nur weil ein System mit „IDOR" gekennzeichnet ist, bedeutet das nicht, dass es die spezifische, gefährliche „Broken Object"-Schwachstelle aufweist. Sicherheitsteams überschätzen das Risiko oft, weil sie den Kennzeichnungen zu sehr vertrauen.
2. Die zwei Hauptbösewichte (Die Taxonomie)
Die Forscher sortierten die echten Fehler in sechs Kategorien ein. Zwei davon waren die klaren Gewinner und machten fast 80 % aller Fälle aus:
Bösewicht A: Die „Direct Object Reference" (Der Telefonbuch-Trick)
- Was es ist: Sie sehen eine URL wie
website.com/invoice/101. Sie ändern die Nummer in102, und plötzlich sehen Sie die Rechnung eines anderen. - Die Analogie: Es ist, als würden Sie an einer Reihe von Briefkästen entlanggehen. Sie wissen, dass Ihr Fach Nr. 101 ist. Sie versuchen Nr. 102, das Schloss ist defekt, also öffnen Sie es und lesen die Post Ihres Nachbarn.
- Häufigkeit: Dies trat in 37 % der Fälle auf.
- Was es ist: Sie sehen eine URL wie
Bösewicht B: Das „Action-Level Object" (Der Vandal)
- Was es ist: Dies ist die große Überraschung. Es geht nicht nur darum, die Daten eines anderen zu lesen, sondern sie zu ändern oder zu löschen.
- Die Analogie: Sie gehen zum Briefkasten Ihres Nachbarn (den Sie nicht berühren dürfen), und anstatt nur die Post zu lesen, reißen Sie den Briefkasten von der Wand, löschen deren E-Mails oder überweisen ihr Geld.
- Häufigkeit: Dies trat in 42 % der Fälle auf.
- Warum es wichtig ist: Die meisten Sicherheitsleitfäden konzentrieren sich auf das „Lesen" von Daten. Dieses Papier sagt: „Hey, die Bösen zerstören und ändern Daten tatsächlich häufiger, als sie nur spionieren."
3. Die anderen hinterhältigen Bösewichte
Die verbleibenden 20 % der Fehler waren komplexer:
- Tenant Isolation (Mietertrennung): Sie befinden sich in einem geteilten Bürogebäude. Sie versuchen, die Tür zu einer Bürosuite eines anderen Unternehmens zu öffnen, und das Schloss versagt.
- Workflow-Context (Arbeitsablauf-Kontext): Sie wurden von einem Unternehmen entlassen, aber das System lässt Sie weiterhin auf die „archivierten" Dateien eines Projekts zugreifen, an dem Sie früher gearbeitet haben, weil das System vergessen hat, Ihren Status zu aktualisieren.
- Chained Disclosure (Kettenoffenlegung): Sie können die ID nicht erraten, finden aber eine Liste von IDs in einem anderen Teil der App (wie einer Quittung) und nutzen diese Liste, um in die Konten anderer Leute einzubrechen.
- Object Rebinding (Objekt-Neubindung): Sie täuschen dem System vor, dass Sie das Objekt besitzen, indem Sie ein verstecktes Feld in der Anfrage ändern (wie den „Eigentümer"-Namen auf einem Dokument).
4. Die „Vertikale" Überraschung (Die Fahrt im Aufzug)
Normalerweise denken wir an diese Angriffe als „Horizontal" (Benutzer A stiehlt von Benutzer B).
- Die Erkenntnis: In 12 % der Fälle gelang es einem regulären Benutzer, auf Dinge zuzugreifen oder sie zu löschen, die einem Administrator gehörten.
- Die Analogie: Ein normaler Mieter im Wohnkomplex schafft es, in das private Büro des Hausverwalters zu gehen und die Hauptschlüssel zu löschen.
- Fazit: Dies ist ein enormes Risiko, das die meisten Sicherheitschecklisten ignorieren, weil sie davon ausgehen, dass „Administratoren sicher sind".
5. Die „magischen" IDs funktionieren nicht
Entwickler denken oft: „Wenn wir keine einfachen Zahlen wie 1, 2, 3 verwenden, sondern lange, zufällige Codes (UUIDs) oder codierte Strings, sind wir sicher."
- Die Erkenntnis: 39 % der erfolgreichen Angriffe verwendeten diese „komplexen" IDs.
- Die Analogie: Die Bösen fanden einen Weg, den „Geheimcode" auf dem Briefkasten zu entschlüsseln, stellten fest, dass es sich nur um eine versteckte Nummer handelte, und erhöhten dann einfach die Nummer, um zum nächsten Briefkasten zu gelangen.
- Fazit: Das Verstecken der ID löst das Problem nicht. Der Server muss immer noch prüfen, ob Sie das Objekt besitzen, unabhängig davon, wie die ID aussieht.
6. Die „GraphQL"-Lücke
Das Papier stellte fest, dass viele moderne Apps ein System namens GraphQL verwenden. Diese Systeme verwenden „Globale IDs" (wie gid://hackerone/Report/123).
- Die Erkenntnis: Angreifer stellten fest, dass diese IDs beim Decodieren die darunterliegenden sequentiellen Zahlen offenlegten, was es ihnen ermöglichte, die nächste ID leicht zu erraten.
- Fazit: Nur weil eine ID wie ein komplexer Zeichenstring aussieht, bedeutet das nicht, dass sie zufällig ist.
Zusammenfassung für den Durchschnittsbürger
Dieses Papier sagt uns Folgendes:
- Vertrauen Sie den Kennzeichnungen nicht: Nur weil ein System als fehlerhaft für einen bestimmten Fehler markiert ist, bedeutet das nicht, dass es tatsächlich auf diese spezifische Weise kaputt ist.
- Die Bösen sind destruktiv: Sie stehlen nicht nur Daten; sie löschen und ändern sie häufiger, als wir dachten.
- Geheime Codes reichen nicht aus: Die Verwendung komplexer IDs hält Hacker nicht auf, wenn der Server nicht prüft, wem die Daten gehören.
- Normale Benutzer können Administratoren schaden: Ein normales Benutzerkonto kann manchmal in die Dinge des „Chefs" einbrechen.
Das Papier kommt zu dem Schluss, dass Sicherheitstests geändert werden müssen. Wir müssen aufhören, nur zu prüfen, ob Sie die Daten eines anderen lesen können, und beginnen zu prüfen, ob Sie sie löschen oder ändern können, und wir müssen testen, ob normale Benutzer versehentlich (oder absichtlich) in die Sachen des Administrators einbrechen können.
Ertrinken Sie in Arbeiten in Ihrem Fachgebiet?
Erhalten Sie tägliche Digests der neuesten Arbeiten passend zu Ihren Forschungsbegriffen — mit technischen Zusammenfassungen, in Ihrer Sprache.