IDOR-Schwachstellen erklärt: Warum sie in modernen Anwendungen bestehen bleiben

Insecure Direct Object References, gemeinhin als IDORs bezeichnet, bleiben eine der häufigsten und schädlichsten Klassen von Anwendungsschwachstellen. Obwohl sie gut dokumentiert und auf konzeptioneller Ebene weitgehend verstanden sind, treten sie weiterhin in realen Produktionssystemen auf, insbesondere in modernen, API-gesteuerten Anwendungen.

Eine IDOR-Schwachstelle tritt auf, wenn eine Anwendung einen vom Benutzer bereitgestellten Bezeichner verwendet, um auf ein internes Objekt zuzugreifen, ohne zu überprüfen, ob der aktuelle Benutzer zum Zugriff auf dieses spezifische Objekt berechtigt ist. Dieses Problem fällt in die umfassendere Kategorie der fehlerhaften Zugriffskontrolle, unterscheidet sich jedoch in seiner Manifestation und warum es schwierig ist, es vollständig zu beseitigen.

IDORs bestehen nicht, weil Teams sie nicht kennen, sondern weil sie aus der Entwicklung realer Systeme entstehen. Sie werden oft an den Rändern von Workflows, bei Refactorings oder wenn Besitzannahmen über Schritte hinweg wiederverwendet werden, die ursprünglich nicht miteinander verbunden sein sollten, eingeführt. 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 Besitzfehler in laufenden Systemen validieren.

Was ist eine Insecure Direct Object Reference in der Praxis

Eine IDOR-Schwachstelle tritt auf, wenn eine Anwendung einen Bezeichner akzeptiert, der auf ein internes Objekt verweist, wie z. B. einen Datensatz, ein Dokument oder ein Konto, und diesen direkt verwendet, ohne die Autorisierung für dieses Objekt konsistent durchzusetzen.

Bezeichner erscheinen häufig als:

• Benutzer-IDs in URL-Pfaden
• Bestell- oder Rechnungs-IDs in Abfrageparametern
• Ressourcen-Bezeichner in Request-Bodies

Die Schwachstelle ist nicht der Bezeichner selbst. Die Schwachstelle ist die Annahme, dass der Bezeichner dem authentifizierten Benutzer gehört, ohne diese Annahme auf dem Server erneut zu validieren.

In modernen Anwendungen gilt diese Annahme oft an den meisten Stellen, aber nicht überall. Diese Inkonsistenz ist der Ort, an dem IDORs existieren.

Warum IDOR-Schwachstellen in APIs besonders gefährlich sind

In der Literatur zur API-Sicherheit werden IDORs oft als Broken Object Level Authorization (BOLA) bezeichnet, das größte Risiko in den OWASP API Security Top 10. OWASP hat den Begriff BOLA eingeführt, um dem modernen API-Design gerecht zu werden.

APIs legen zentrale Anwendungsfunktionen und Daten offen. Wenn eine IDOR in einer API existiert, können Angreifer sie oft in großem Umfang ausnutzen.

Häufige Auswirkungen sind:

• Zugriff auf sensible Daten anderer Benutzer
  
• Ändern oder Löschen von Ressourcen im Besitz anderer
  
• Umgehung von Geschäftsregeln, die an Besitz oder Rolle gebunden sind
  
• Untergrabung von Workflows wie Genehmigungen, Abrechnung oder Kontoverwaltung
  

Da APIs für die Automatisierung konzipiert sind, kann eine einzige fehlende Besitzprüfung große Teile eines Systems kompromittieren.

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 auf Objekte eines anderen Benutzers mit demselben Berechtigungslevel zu
  
• Vertikale IDOR: Identifikatoren ermöglichen den Zugriff auf privilegierte oder administrative Objekte
  
• Blinde IDOR: Die Antwort legt keine Daten offen, aber die Aktion ist erfolgreich auf dem Objekt eines anderen Benutzers
  

Blinde IDORs sind besonders leicht zu übersehen mit Tools, die sich auf offensichtliche Datenexposition konzentrieren. Sie erfordern oft eine explizite Validierung, um die Auswirkungen zu bestätigen.

Wie IDOR-Schwachstellen traditionell in der Praxis getestet werden

Während eines Penetrationstests werden IDOR-Tests typischerweise durch sorgfältiges Wiederholen und Vergleichen von Anfragen durchgeführt.

In der Praxis umfasst 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
  
• Vergleichen von Antworten, um zu sehen, ob sich das Verhalten ändert
  

Wenn beispielsweise eine Anfrage, die nur Daten für Benutzer A zurückgeben sollte, dieselben Daten zurückgibt, wenn sie als Benutzer B wiederholt wird, weist dies auf eine fehlerhafte Zugriffskontrolle hin.

Dieser Ansatz ist effektiv und weit verbreitet. Er basiert auf dem Verständnis des Testers für die Anwendungsabsicht und seiner Fähigkeit, zu beurteilen, welche Anfragen sicherheitsrelevant sind.

Er ist jedoch auch von Natur aus manuell und zeitaufwendig. Jeder zusätzliche Workflow, jede Rolle oder jeder Zustandsübergang vervielfacht die Anzahl der Anfragen, die erfasst, wiederholt und interpretiert werden müssen. Mit zunehmender Komplexität von Anwendungen wird es unpraktisch, diesen Vergleich erschöpfend auf alle möglichen Pfade anzuwenden.

Deshalb findet manuelles Testen oft IDORs in Bereichen, die besondere Aufmerksamkeit erhalten, aber keine umfassende Abdeckung garantieren kann.

Warum DAST-Tools echte IDOR-Schwachstellen übersehen

Dynamische Anwendungssicherheitstests-Tools arbeiten auf der Anfragenebene. 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 Benutzer A oder Benutzer B gehört. Er berücksichtigt weder Besitzverhältnisse, Workflow-Kontext noch, ob eine Antwort für die authentifizierte Identität angemessen ist. Solange die Anwendung sauber antwortet, oft mit einem 200 OK, kann ein Scanner die Interaktion als erfolgreich betrachten, selbst wenn sensible Daten dem falschen Benutzer zugänglich gemacht werden.

Dies macht DAST nützlich für oberflächliche Probleme, aber grundsätzlich begrenzt, wenn es um IDORs und andere Autorisierungsfehler geht, die von Objektbesitz und Kontext abhängen. Diese Einschränkung ist nicht spezifisch für ein bestimmtes Tool. Sie spiegelt die Tatsache wider, dass Request-Level-Scanning, selbst wenn gut implementiert, nicht genügend Kontext hat, um über Objektbesitz und Workflow-Absicht zu urteilen.

Warum statische Analyse Rauschen um IDORs erzeugt

Viele Teams verlassen sich auf statische Analysetools, um potenzielle IDOR-Probleme zu kennzeichnen. Diese Tools suchen typischerweise nach Mustern, bei denen Identifikatoren an Handler oder Controller übergeben werden, ohne dass offensichtliche Autorisierungsprüfungen in der Nähe vorhanden sind.

Dies führt oft zu einer großen Anzahl von Funden.

In der Praxis sind die meisten davon False Positives. Autorisierungsprüfungen existieren häufig an anderer Stelle in der Aufrufkette, in gemeinsam genutzter Middleware oder auf Framework-Ebene. Statische Analyse kann nicht zuverlässig feststellen, ob ein Identifikator zur Laufzeit ausnutzbar ist.

Dieses Problem wird verstärkt, wenn die Autorisierung implizit oder über verschiedene Schichten verteilt implementiert ist, einschließlich:

• Zugriffskontrolle, die durch Middleware oder Decorators durchgesetzt wird
  
• Prüfungen, die in gemeinsamen Diensten oder Modellmethoden implementiert sind
  
• Berechtigungslogik, die über mehrere Dateien und Aufrufpfade verteilt ist
  

In diesen Fällen sehen statische Tools einen Identifier und einen Datenzugriffspfad, übersehen aber den vollständigen Autorisierungskontext. Das Ergebnis ist eine hohe Anzahl plausibel aussehender Ergebnisse mit geringer Konfidenz.

Dies ist eine grundlegende Einschränkung der statischen Analyse. Ohne Laufzeitstatus und Identitätskontext kann keine Code-Level-Analyse zuverlässig bestimmen, ob eine Objektreferenz in der Praxis ausnutzbar ist.

Selbst KI-gestützte statische Analysetools bleiben prädiktiv. Sie analysieren die Codestruktur, können aber das Laufzeitverhalten nicht bestätigen. Infolgedessen weisen IDOR-ähnliche Befunde oft Falsch-Positiv-Raten von über fünfzig Prozent auf, was Teams dazu zwingt, theoretische Probleme zu triagieren, während echte Eigentumsfehler Gefahr laufen, übersehen zu werden.

Das Kernproblem: Eigentum ist kontextabhängig

IDORs sind nicht einfach nur fehlende Prüfungen. Sie sind Fehler der kontextuellen Autorisierung, die an die Objekteigentümerschaft gebunden sind.

Eigentum wird durch eine Kombination aus Folgendem hergestellt:

• Authentifizierungsstatus
  
• Rollen- und Berechtigungsmodelle
  
• Workflow-Fortschritt
  
• Serverseitiger Status, der früher in einem Prozess erstellt wurde
  

Wenn ein Teil dieses Kontexts angenommen wird, anstatt neu validiert zu werden, kann eine IDOR entstehen.

Einige IDORs sind Second-Order. Ein Identifier 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 über Zeit und Schritte hinweg verteilt ist.

Das zuverlässige Testen von IDORs erfordert, wiederholt eine einfache Frage zu stellen: Was passiert, wenn dieser Identifier jemand anderem gehört?

UUIDs verhindern keine IDOR-Schwachstellen

Es ist ein weit verbreitetes Missverständnis, dass der Wechsel von sequenziellen Identifiers zu UUIDs das IDOR-Risiko eliminiert.

Unvorhersehbare Identifier reduzieren Brute-Force-Angriffe. Sie verhindern keinen unbefugten Zugriff, wenn Eigentumsprüfungen fehlen.

In realen Systemen erlangen Angreifer Identifier durch normales Anwendungsverhalten, einschließlich:

• Referenzen, die von anderen Endpunkten zurückgegeben werden
  
• Geteilte Links und URLs
  
• In-App-Nachrichten und Benachrichtigungen
  
• Logs, Exporte und Browserverlauf
  

Wenn ein Angreifer einen gültigen Identifier erlangen kann und das Backend die Eigentümerschaft nicht durchsetzt, besteht immer noch eine IDOR.

Wie KI-Penetrationstests IDOR-Schwachstellen finden, die andere übersehen

KI-Penetrationstests verfolgen einen anderen Ansatz zur Identifizierung von Autorisierungsfehlern.

Anstatt bei der Erkennung stehen zu bleiben, testet es aktiv Hypothesen über Eigentumsrechte und Zugriffskontrolle in einer laufenden Anwendung.

Innerhalb von Aikido wird dieser Ansatz durch Aikido Attack umgesetzt, ein autonomer Penetrationstest, der menschliche Kreativität mit Maschinengeschwindigkeit verbindet. Er ist darauf ausgelegt, Autorisierungs- und Eigentumsfehler in realen Umgebungen zu bewerten. Aikido Attack arbeitet mit realen Identitäten, führt Workflows durchgängig aus und validiert die Ausnutzbarkeit, bevor Ergebnisse gemeldet werden.

Für IDORs umfasst dieser Prozess:

• Authentifizierung als reale Benutzer
  
• Durchgängiges Ausführen vollständiger Workflows
  
• Wiederverwendung von Objekt-Identifikatoren über Rollen und Kontexte hinweg
  
• Versuch, auf Ressourcen zuzugreifen oder diese zu modifizieren, die anderen Benutzern gehören
  
• Validierung, ob das Verhalten ausnutzbar und reproduzierbar ist
  

Nur Probleme, die in der Praxis ausgenutzt werden können, werden gemeldet. Der Rest wird automatisch verworfen.

Dies reduziert Fehlalarme und stellt sicher, dass gemeldete Ergebnisse echte Autorisierungsfehler darstellen. In Situationen, in denen die Absicht unklar ist, müsste ein menschlicher Tester normalerweise den Anwendungsbesitzer konsultieren. Die Laufzeitvalidierung löst dies direkt.

Gezielte Tests von Eigentumsannahmen

KI-Penetrationstests wenden gezielte Anstrengungen auf, um Eigentumsannahmen zu bewerten, die an Objekt-Identifikatoren innerhalb einer Anwendung gebunden sind.

Anstatt IDORs als Nebeneffekt generischer Tests zu behandeln, konzentriert es sich explizit auf:

• Identifikatoren, die an Benutzerdefinierte Ressourcen gebunden sind
  
• Workflow-Übergänge, die Objektreferenzen wiederverwenden
  
• Backend-Endpunkte, die sich auf Frontend-Eigentumsannahmen verlassen
  

Dies gewährleistet eine konsistente Abdeckung der Systemteile, in denen IDORs tatsächlich auftreten.

Beispiel: IDOR in einem mehrstufigen Genehmigungs-Workflow

Dieses Beispiel veranschaulicht, wie eine IDOR über mehrere Workflow-Schritte hinweg entstehen kann, selbst wenn einzelne Endpunkte die Zugriffskontrolle korrekt durchzusetzen scheinen.

Anwendungskontext

Die Anwendung umfasst einen mehrstufigen Genehmigungs-Workflow für sensible Aktionen. Ein Benutzer erstellt eine Anfrage, die später überprüft und genehmigt werden muss. Jede Anfrage ist an den Benutzer gebunden, der sie erstellt hat und wird durch einen Identifikator referenziert, der über mehrere API-Aufrufe hinweg verwendet wird.

Nur der Eigentümer einer Anfrage darf diese vor der Genehmigung anzeigen oder ändern.

Was das System beobachtete

KI-Penetrationstests authentifizierten sich als StandardBenutzer und durchliefen den Workflow zur Anforderungserstellung. Dabei speicherte das System einen Zwischenzustand des Workflows auf dem Server und nutzte diesen in späteren Schritten wieder.

Erste Eigentumsprüfungen wurden korrekt durchgesetzt, als die Anforderung erstellt wurde.

Eigentumsprüfung über den gesamten Workflow hinweg

Weitere Tests bewerteten, wie der Anforderungsidentifikator in späteren Phasen verwendet wurde. Dabei wurde festgestellt, dass:

• Der Identifikator beim Fortsetzen einer ausstehenden Anforderung wiederverwendet wurde
  
• Spätere API-Aufrufe gingen aufgrund einer früheren Validierung von Besitz aus
  
• Der Besitz nicht erneut validiert wurde, als der Workflow fortgesetzt wurde
  

Durch das Wiederholen der Fortsetzungsaktion mit einem anderen authentifizierten Benutzer und das Ersetzen des Anforderungsidentifikators konnte das System auf eine Anforderung zugreifen und diese bearbeiten, die es nicht besaß.

Warum dies eine IDOR-Schwachstelle war

Das Problem entstand nicht aus einer einzelnen fehlenden Prüfung.

Es resultierte aus der Annahme, dass der Besitz bereits früher im Workflow validiert worden war und nicht erneut überprüft werden musste, wenn die Anforderung fortgesetzt wurde. Diese Annahme scheiterte, sobald Objektidentifikatoren über Benutzer hinweg wiederverwendet wurden.

Validierung und Reproduzierbarkeit

Vor der Meldung des Problems hat das System:

• Die vollständige Sequenz mehrfach wiederholt
  
• Konsistentes Verhalten bestätigt
  
• Beweise für unbefugten Zugriff erfasst
  

Erst nachdem Reproduzierbarkeit und Auswirkungen bestätigt wurden, wurde das Problem gemeldet.

Warum dies von anderen Ansätzen übersehen würde

Jeder einzelne Endpunkt verhielt sich isoliert korrekt. Die Schwachstelle trat nur auf, wenn:

• Ein Workflow teilweise abgeschlossen wurde
  
• Serverseitiger Zustand wiederverwendet wurde
  
• Ein späterer Schritt außerhalb des ursprünglichen Benutzerkontexts aufgerufen wurde
  

Dies machte das Problem schwierig durch manuelles Testen zu erkennen und unsichtbar für anforderungsbasierte Scanning-Tools.

Warum kontinuierliches Testen für IDOR-Schwachstellen wichtig ist

IDORs werden oft durch Änderungen eingeführt.

Sie treten häufig auf, wenn:

• Neue Funktionen bestehende Datenmodelle wiederverwenden
  
• Autorisierungslogik an einer Stelle hinzugefügt wird, aber an einer anderen nicht
  
• Refactorings unbeabsichtigt frühere Eigentumsprüfungen umgehen
  

Ein Zeitpunkt-Test mag bestätigen, dass die Eigentumsrechte heute durchgesetzt werden, doch diese Gewissheit nimmt ab, wenn sich die Anwendung weiterentwickelt.

Kontinuierliches KI-gesteuertes Testen bewahrt das Vertrauen, indem es Eigentumsannahmen neu bewertet, wenn sich die Software ändert. Tools für kontinuierliches Penetrationstesten unterstützen dies, indem sie neue und modifizierte Workflows kontinuierlich auf unautorisierten Objektzugriff testen.

IDOR-Schwachstellen als Symptom von Systemkomplexität

IDORs sind keine Randfälle. Sie sind ein natürliches Ergebnis komplexer Systeme, die sich im Laufe der Zeit entwickeln.

Mit dem Wachstum von Anwendungen verteilt sich die Eigentumslogik über Dienste, Workflows und Schichten. Annahmen häufen sich an, und die Argumentation über den Zugriff auf Objektebene wird zunehmend schwieriger.

KI-Penetrationstests beseitigen diese Komplexität nicht, aber sie machen sie testbar.

Indem Workflows systematisch ausgeführt, der Zustand verfolgt und die Eigentumsrechte im Kontext validiert werden, verwandelt es eine der hartnäckigsten Schwachstellenklassen in etwas, das früher, konsistenter und mit größerer Zuversicht erkannt werden kann.

Sicherheitsteams priorisieren IDORs und andere Autorisierungsfehler zunehmend, da diese systemspezifisch, regressionsanfällig und ohne workflow-bewusstes Laufzeittesting schwer zu validieren sind.


Das könnte Sie auch interessieren:

• Top KI-Penetrationstest-Tools
• DAST vs. KI-Penetrationstests vs. manuelles Penetrationstesten
• Was sind KI-Penetrationstests?

Lassen Sie noch heute einen Pentest mit Aikido Attack durchführen.