Unsichere direkte Objektreferenzen, allgemein als IDORs bezeichnet, gehören nach wie vor zu den häufigsten und schädlichsten Arten von Anwendungsschwachstellen. Obwohl sie gut dokumentiert sind und auf konzeptioneller Ebene allgemein verstanden werden, treten sie weiterhin in realen Produktionssystemen auf, insbesondere in modernen, API-gesteuerten Anwendungen.
Eine IDOR-Sicherheitslücke tritt auf, wenn eine Anwendung eine vom Benutzer bereitgestellte Kennung verwendet, um auf ein internes Objekt zuzugreifen, ohne zu überprüfen, ob der aktuelle Benutzer zum Zugriff auf dieses bestimmte Objekt berechtigt ist. Dieses Problem fällt unter die übergeordnete Kategorie fehlerhafte Zugriffskontrolle, unterscheidet sich jedoch in seiner Ausprägung und den Gründen, warum es schwierig ist, es vollständig zu beseitigen.
IDORs bestehen nicht, weil Teams sich ihrer nicht bewusst sind, sondern weil sie aus der Entwicklung realer Systeme hervorgehen. Sie treten häufig an den Rändern von Workflows, während Refactorings oder wenn Eigentumsannahmen über Schritte hinweg wiederverwendet werden, die ursprünglich nicht miteinander verbunden waren. Dieser Artikel erklärt, wie IDORs in der Praxis aussehen, warum gängige Sicherheitstestansätze Schwierigkeiten haben, sie zuverlässig zu erkennen, und wie moderne Testtechniken Eigentumsfehler in laufenden Systemen validieren.
Was ist eine unsichere direkte Objektreferenz in der Praxis?
Eine IDOR-Sicherheitslücke tritt auf, wenn eine Anwendung eine Kennung akzeptiert, die auf ein internes Objekt wie einen Datensatz, ein Dokument oder ein Konto verweist, und diese direkt verwendet, ohne die Autorisierung für dieses Objekt konsequent durchzusetzen.
Identifikatoren erscheinen üblicherweise wie folgt:
- Benutzer-IDs in URL-Pfaden
- Bestell- oder Rechnungsnummern in Abfrageparametern
- Ressourcenidentifikatoren in Anfragetexten
Die Schwachstelle liegt nicht in der Kennung selbst. Die Schwachstelle liegt in der Annahme, dass die Kennung dem authentifizierten Benutzer gehört, ohne diese Annahme auf dem Server erneut zu überprüfen.
In modernen Anwendungen trifft diese Annahme oft an den meisten Stellen zu, jedoch nicht überall. Diese Inkonsistenz ist der Grund für das Vorhandensein von IDORs.
Warum IDOR-Schwachstellen in APIs besonders gefährlich sind
In API-Sicherheit werden IDORs oft als Broken Object Level Authorization (BOLA) bezeichnet, das größte Risiko in den OWASP API-Sicherheit 10. OWASP hat den Begriff BOLA eingeführt, um dem modernen API-Design gerecht zu werden.
APIs legen die Kernfunktionalität und Daten einer Anwendung offen. Wenn eine API eine IDOR enthält, können Angreifer diese oft in großem Umfang ausnutzen.
Zu den häufigsten Auswirkungen gehören:
- Zugriff auf sensible Daten anderer Benutzer
- Ändern oder Löschen von Ressourcen, die anderen gehören
- Umgehung von Geschäftsregeln, die an Eigentumsverhältnisse oder Rollen gebunden sind
- Untergrabung von Arbeitsabläufen wie Genehmigungen, Rechnungsstellung oder Kontoverwaltung
Da APIs für die Automatisierung konzipiert sind, kann eine einzige fehlende Eigentumsprüfung große Teile eines Systems gefährden.
Häufige Arten von IDOR-Schwachstellen
IDOR ist ein Oberbegriff. In der Praxis stoßen Teams auf mehrere wiederkehrende Muster:
- Horizontale IDOR: Ein Benutzer greift mit denselben Berechtigungen auf die Objekte eines anderen Benutzers zu.
- Vertikale IDOR: Identifikatoren ermöglichen den Zugriff auf privilegierte oder administrative Objekte.
- Blind IDOR: Die Antwort gibt keine Daten preis, aber die Aktion wird auf dem Objekt einer anderen Person erfolgreich ausgeführt.
Blinde IDORs sind mit Tools, die sich auf offensichtliche Datenoffenlegungen konzentrieren, besonders leicht zu übersehen. Oftmals erfordern sie eine explizite Validierung, um ihre Auswirkungen zu bestätigen.
Wie IDOR-Schwachstellen traditionell in der Praxis getestet werden
Bei einem Penetrationstest wird das IDOR-Testing in der Regel durch sorgfältiges Wiederholen und Vergleichen von Anfragen durchgeführt.
In der Praxis bedeutet dies:
- Authentifizierung als legitimer Benutzer
- Ausführen von Workflows über die Benutzeroberfläche
- Erfassen von Anfragen, die vom Browser oder Client gesendet werden
- Wiederholen dieser Anfragen mit einem anderen authentifizierten Benutzer
- Vergleich der Antworten, um festzustellen, ob sich das Verhalten ändert
Wenn beispielsweise eine Anfrage, die nur Daten für Benutzer A zurückgeben sollte, bei der Wiederholung als Benutzer B dieselben Daten zurückgibt, deutet dies auf fehlerhafte Zugriffskontrolle hin.
Dieser Ansatz ist effektiv und weit verbreitet. Er basiert auf dem Verständnis des Testers für die Absicht der Anwendung und seiner Fähigkeit, zu beurteilen, welche Anfragen sicherheitsrelevant sind.
Allerdings ist dieser Vorgang naturgemäß manuell und zeitaufwendig. Jeder zusätzliche Workflow, jede zusätzliche Rolle oder jeder zusätzliche Statusübergang vervielfacht die Anzahl der Anfragen, die erfasst, wiedergegeben und interpretiert werden müssen. Mit zunehmender Komplexität der Anwendungen wird es unpraktisch, diesen Vergleich für alle möglichen Pfade erschöpfend anzuwenden.
Aus diesem Grund werden bei manuellen Tests häufig IDORs in Bereichen gefunden, die besonders aufmerksam geprüft werden, jedoch kann keine umfassende Abdeckung garantiert werden.
Warum DAST echte IDOR-Schwachstellen übersehen
Dynamische Anwendungssicherheitstests arbeiten auf Anforderungsebene. Sie crawlen Endpunkte, fuzzen Eingaben und suchen nach anomalen Antworten. Was sie nicht verstehen, ist die Absicht. Ein Scanner weiß nicht, ob eine bestimmte Rechnung zu Benutzer A oder Benutzer B gehört. Er berücksichtigt weder Eigentumsverhältnisse noch den Workflow-Kontext und auch nicht, ob eine Antwort für die authentifizierte Identität angemessen ist. Solange die Anwendung einwandfrei reagiert, oft mit einem 200 OK, kann ein Scanner die Interaktion als erfolgreich behandeln, selbst wenn sensible Daten dem falschen Benutzer zugänglich gemacht werden.
Dadurch DAST für Probleme auf Oberflächenebene, ist jedoch grundsätzlich eingeschränkt, wenn es um IDORs und andere Autorisierungsfehler geht, die von der Objekteigentümerschaft und dem Kontext abhängen. Diese Einschränkung gilt nicht nur für ein bestimmtes Tool. Sie spiegelt die Tatsache wider, dass Scans auf Anforderungsebene selbst bei guter Implementierung nicht über genügend Kontext verfügen, um Rückschlüsse auf die Objekteigentümerschaft und die Absicht des Workflows zu ziehen.
Warum statische Analysen zu Verwirrung rund um IDORs führen
Viele Teams verlassen sich auf statische Analyse-Tools, um potenzielle IDOR-Probleme zu erkennen. Diese Tools suchen in der Regel nach Mustern, bei denen Identifikatoren an Handler oder Controller übergeben werden, ohne dass in der Nähe offensichtliche Autorisierungsprüfungen stattfinden.
Dies führt oft zu einer Vielzahl von Befunden.
In der Praxis handelt es sich dabei meist um Fehlalarme. Autorisierungsprüfungen finden häufig an anderer Stelle in der Aufrufkette, in gemeinsam genutzter Middleware oder auf Framework-Ebene statt. Eine statische Analyse kann nicht zuverlässig feststellen, ob eine Kennung zur Laufzeit ausgenutzt werden kann.
Dieses Problem wird noch verstärkt, wenn die Autorisierung implizit oder über mehrere Ebenen verteilt implementiert wird, darunter:
- Zugriffskontrolle durch Middleware oder Dekoratoren
- In Shared Services oder Modellmethoden implementierte Prüfungen
- Berechtigungslogik verteilt auf mehrere Dateien und Aufrufpfade
In diesen Fällen erkennen statische Tools zwar eine Kennung und einen Datenzugriffspfad, übersehen jedoch den vollständigen Autorisierungskontext. Das Ergebnis ist eine große Anzahl plausibel erscheinender Ergebnisse mit geringer Zuverlässigkeit.
Dies ist eine grundlegende Einschränkung der statischen Analyse. Ohne Laufzeitstatus und Identitätskontext kann keine Analyse auf Codeebene zuverlässig feststellen, ob eine Objektreferenz in der Praxis ausnutzbar ist.
Selbst KI-gestützte statische Analyse-Tools bleiben prädiktiv. Sie analysieren die Codestruktur, können jedoch das Laufzeitverhalten nicht bestätigen. Infolgedessen weisen IDOR-ähnliche Ergebnisse oft eine Falsch-Positiv-Rate von über fünfzig Prozent auf, was Teams dazu zwingt, triage Probleme triage , während echte Eigentumsfehler möglicherweise übersehen werden.
Das Kernproblem: Eigentum ist kontextabhängig
IDORs sind nicht einfach fehlende Überprüfungen. Es handelt sich um Fehler bei der kontextbezogenen Autorisierung, die mit dem Eigentumsrecht an Objekten verbunden sind.
Das Eigentumsrecht wird durch eine Kombination aus folgenden Faktoren begründet:
- Authentifizierungsstatus
- Rollen- und Berechtigungsmodelle
- Workflow-Fortschritt
- Zuvor in einem Prozess erstellter serverseitiger Status
Wenn ein Teil dieses Kontexts angenommen statt erneut überprüft wird, kann ein IDOR entstehen.
Einige IDORs sind zweiter Ordnung. Ein Identifikator wird in einem Schritt akzeptiert, gespeichert und erst später verwendet, wenn die Zugriffskontrolle nicht mehr überprüft wird. Diese Probleme sind besonders schwer zu erkennen, da der Exploit zeitlich und schrittweise getrennt ist.
Um IDORs zuverlässig zu testen, muss wiederholt eine einfache Frage gestellt werden: Was passiert, wenn diese Kennung jemand anderem gehört?
UUIDs verhindern keine IDOR-Sicherheitslücken
Es ist ein weit verbreiteter Irrglaube, dass durch die Umstellung von sequenziellen Identifikatoren auf UUIDs das IDOR-Risiko beseitigt wird.
Unvorhersehbare Identifikatoren reduzieren Brute-Force-Angriffe. Sie verhindern jedoch keinen unbefugten Zugriff, wenn keine Eigentumsprüfungen durchgeführt werden.
In realen Systemen erhalten Angreifer Identifikatoren durch normales Anwendungsverhalten, darunter:
- Von anderen Endpunkten zurückgegebene Referenzen
- Geteilte Links und URLs
- In-App-Nachrichten und Benachrichtigungen
- Protokolle, Exporte und Browserverlauf
Wenn ein Angreifer eine gültige Kennung erhalten kann und das Backend keine Eigentumsrechte durchsetzt, besteht weiterhin eine IDOR.
Wie KI-Penetrationstests IDOR-Schwachstellen KI-Penetrationstests , die andere übersehen
KI-Penetrationstests verfolgt einen anderen Ansatz zur Identifizierung von Autorisierungsfehlern.
Anstatt sich auf die Erkennung zu beschränken, testet es aktiv Hypothesen über Eigentumsrechte und Zugriffskontrollen in einer laufenden Anwendung.
Innerhalb Aikido wird dieser Ansatz durch Aikido umgesetzt, ein autonomes Penetrationstestverfahren, das menschliche Kreativität mit maschineller Geschwindigkeit verbindet. Es wurde entwickelt, um Autorisierungs- und Eigentumsfehler in realen Umgebungen zu bewerten. Aikido arbeitet mit echten Identitäten, führt Workflows von Anfang bis Ende durch und überprüft die Ausnutzbarkeit, bevor die Ergebnisse gemeldet werden.
Für IDORs umfasst dieser Prozess:
- Authentifizierung als echte Benutzer
- Durchführung vollständiger Workflows von Anfang bis Ende
- Wiederverwendung von Objektkennungen über Rollen und Kontexte hinweg
- Der Versuch, auf Ressourcen anderer Benutzer zuzugreifen oder diese zu ändern
- Überprüfen, ob das Verhalten ausnutzbar und reproduzierbar ist
Es werden nur Probleme gemeldet, die in der Praxis ausgenutzt werden können. Die übrigen werden automatisch verworfen.
Dadurch werden Fehlalarme reduziert und sichergestellt, dass gemeldete Ergebnisse tatsächliche Autorisierungsfehler darstellen. In Situationen, in denen die Absicht unklar ist, müsste ein menschlicher Tester in der Regel Rücksprache mit dem Anwendungsinhaber halten. Die Laufzeitvalidierung löst dieses Problem direkt.
Gezielte Prüfung von Eigentumsannahmen
KI-Penetrationstests speziell der Bewertung von Eigentumsannahmen, die mit Objektidentifikatoren in einer Anwendung verbunden sind.
Anstatt IDORs als Nebeneffekt generischer Tests zu betrachten, konzentriert es sich ausdrücklich auf:
- Identifikatoren, die an benutzereigene Ressourcen gebunden sind
- Workflow-Übergänge, die Objektreferenzen wiederverwenden
- Backend-Endpunkte, die auf Annahmen zur Frontend-Verantwortung beruhen
Dadurch wird eine konsistente Abdeckung der Teile eines Systems gewährleistet, in denen IDORs tatsächlich auftreten.
Beispiel: IDOR in einem mehrstufigen Genehmigungsworkflow
Dieses Beispiel veranschaulicht, wie ein IDOR über mehrere Workflow-Schritte hinweg auftreten kann, selbst wenn einzelne Endpunkte die Zugriffskontrolle scheinbar korrekt durchsetzen.
Anwendungskontext
Die Anwendung umfasst einen mehrstufigen Genehmigungsworkflow für sensible Aktionen. Ein Benutzer erstellt eine Anfrage, die später geprüft und genehmigt werden muss. Jede Anfrage ist mit dem Benutzer verknüpft, der sie erstellt hat, und wird durch eine Kennung referenziert, die über mehrere API-Aufrufe hinweg verwendet wird.
Nur der Eigentümer einer Anfrage darf diese vor der Genehmigung einsehen oder ändern.
Was das System beobachtet hat
KI-Penetrationstests als Standardbenutzer KI-Penetrationstests und der Ablauf der Anforderungserstellung durchgeführt. Während dieses Prozesses speicherte das System den Zwischenstatus des Workflows auf dem Server und verwendete ihn in späteren Schritten wieder.
Die ersten Eigentumsprüfungen wurden bei der Erstellung der Anfrage korrekt durchgeführt.
Eigentumsprüfung im gesamten Workflow
In weiteren Tests wurde untersucht, wie die Anforderungskennung in späteren Phasen verwendet wurde. Dabei wurde Folgendes festgestellt:
- Die Kennung wurde bei der Wiederaufnahme einer ausstehenden Anfrage wiederverwendet.
- Spätere API-Aufrufe übernahmen die Eigentumsrechte auf Grundlage der früheren Validierung.
- Die Eigentumsrechte wurden bei der Wiederaufnahme des Workflows nicht erneut validiert.
Durch Wiederholen der Wiederaufnahmeaktion mit einem anderen authentifizierten Benutzer und Ersetzen der Anforderungskennung konnte das System auf eine Anfrage zugreifen und diese bearbeiten, die ihm nicht gehörte.
Warum dies eine IDOR-Sicherheitslücke war
Das Problem entstand nicht aufgrund einer einzigen fehlenden Überprüfung.
Dies resultierte aus der Annahme, dass die Eigentumsrechte bereits zu einem früheren Zeitpunkt im Workflow überprüft worden waren und bei Wiederaufnahme der Anfrage nicht erneut überprüft werden mussten. Diese Annahme erwies sich als falsch, sobald Objektkennungen von mehreren Benutzern wiederverwendet wurden.
Validierung und Reproduzierbarkeit
Bevor das Problem gemeldet wird, führt das System folgende Schritte durch:
- Die gesamte Sequenz mehrmals wiederholt
- Bestätigtes konsistentes Verhalten
- Beweise für unbefugten Zugriff gesichert
Erst nachdem die Reproduzierbarkeit und die Auswirkungen bestätigt worden waren, wurde das Problem gemeldet.
Warum dies bei anderen Ansätzen übersehen würde
Jeder einzelne Endpunkt verhielt sich isoliert betrachtet korrekt. Die Schwachstelle trat nur auf, wenn:
- Ein Arbeitsablauf wurde teilweise abgeschlossen.
- Der serverseitige Status wurde wiederverwendet.
- Ein späterer Schritt wurde außerhalb des ursprünglichen Benutzerkontexts aufgerufen.
Dadurch war das Problem bei manuellen Tests schwer zu erkennen und für anforderungsbasierte Scan-Tools unsichtbar.
Warum kontinuierliche Tests für IDOR-Sicherheitslücken wichtig sind
IDORs werden oft durch Veränderungen eingeführt.
Sie treten häufig auf, wenn:
- Neue Funktionen verwenden vorhandene Datenmodelle wieder.
- Die Autorisierungslogik wird an einer Stelle hinzugefügt, an einer anderen jedoch nicht.
- Refactors umgehen unbeabsichtigt frühere Eigentumsprüfungen
Ein Punkt-in-Zeit-Test kann bestätigen, dass die Eigentumsrechte heute durchgesetzt werden, aber diese Sicherheit nimmt mit der Weiterentwicklung der Anwendung ab.
Kontinuierliche KI-gesteuerte Tests sorgen für Vertrauen, indem sie die Eigentumsverhältnisse bei Softwareänderungen neu bewerten. kontinuierliches Penetrationstesten unterstützen dies, indem sie neue und geänderte Workflows kontinuierlich auf unbefugten Objektzugriff testen.
IDOR-Schwachstellen als Symptom der Systemkomplexität
IDORs sind keine Randfälle. Sie sind das natürliche Ergebnis komplexer Systeme, die sich im Laufe der Zeit weiterentwickeln.
Mit zunehmender Anzahl von Anwendungen verteilt sich die Eigentumslogik über Dienste, Workflows und Ebenen. Annahmen häufen sich, und die Argumentation über den Zugriff auf Objektebene wird immer schwieriger.
KI-Penetrationstests beseitigen diese Komplexität nicht, machen sie jedoch testbar.
Durch die systematische Ausführung von Workflows, die Verfolgung des Status und die Validierung der Eigentumsverhältnisse im Kontext wird eine der hartnäckigsten Schwachstellenklassen zu etwas, das früher, konsistenter und mit größerer Sicherheit erkannt werden kann.
Sicherheitsteams legen zunehmend Wert auf IDORs und andere Autorisierungsfehler, da diese systemspezifisch und anfällig für Regressionen sind und ohne Workflow-orientierte Laufzeittests nur schwer zu validieren sind.
Das könnte Sie auch interessieren:
Lassen Sie noch heute einen Penetrationstest mit Aikido durchführen.
Sichern Sie Ihre Software jetzt.
.avif)
