Was ist IDOR?

IDOR steht für Insecure Direct Object Reference. Die Schwachstelle entsteht, wenn eine Anwendung eine vom Client beeinflussbare Objektkennung verwendet, ohne für das konkrete Objekt und die konkrete Aktion eine Berechtigung zu prüfen. Ein angemeldeter Benutzer kann dadurch Daten anderer Personen oder Mandanten lesen, verändern oder löschen.

Wie entsteht eine IDOR-Schwachstelle?

Ein Endpunkt wie GET /api/orders/4711 liefert eine Bestellung. Ändert der Benutzer die ID auf 4712 und erhält eine fremde Bestellung, vertraut der Server auf die Referenz statt auf eine Autorisierungsentscheidung. Dass der Benutzer korrekt angemeldet ist, reicht nicht: Authentifizierung beantwortet wer anfragt, Autorisierung muss zusätzlich klären, ob diese Identität genau dieses Objekt mit dieser Funktion nutzen darf.

Der Fehler tritt oft auf, wenn die Oberfläche nur eigene Datensätze anzeigt, die API aber jede gültige ID akzeptiert. Clientseitig versteckte Schaltflächen und JavaScript-Prüfungen sind keine serverseitige Zugriffskontrolle.

Wo befinden sich Objektkennungen?

Nicht nur Lesezugriffe sind relevant. Update, Delete, Export, Freigabe, Kommentar, Statuswechsel und Massenoperationen benötigen jeweils eine eigene Prüfung. Auch untergeordnete Objekte müssen zum erwarteten Elternobjekt und Mandanten gehören.

Welche Auswirkungen kann IDOR haben?

Einzelne Datensätze können personenbezogene oder vertrauliche Informationen offenlegen. Automatisierbare Kennungen ermöglichen unter Umständen den Export eines gesamten Kundenbestands. Schreibzugriffe führen zu manipulierten Bestellungen, fremden Freigaben, gelöschten Dateien oder einer Kontoübernahme. Ein Wechsel auf administrative Objekte kann eine vertikale Rechteausweitung erzeugen. Schwere und Umfang hängen daher von Objekt, Aktion und Skalierbarkeit ab – nicht nur davon, ob eine ID geraten wird.

Was unterscheidet IDOR und Broken Access Control?

Broken Access Control ist die breite Schwachstellenklasse. IDOR bezeichnet darin den Fall, dass eine manipulierte Referenz auf ein fremdes Objekt akzeptiert wird. Fehlende Funktionsberechtigungen, erzwungenes Browsing oder eine falsche CORS-Konfiguration sind andere Zugriffskontrollprobleme. In moderner OWASP-Terminologie wird IDOR häufig als Broken Object Level Authorization (BOLA) beschrieben, besonders bei APIs.

Wie wird IDOR verhindert?

1. Für jede Aktion prüfen: Objekt, Benutzer, Rolle, Mandant und gewünschte Operation serverseitig bewerten.
2. Über Beziehungen laden: Statt Order::find($id) sinngemäß nur aus currentUser->orders() auswählen.
3. Zentralisieren: Policies oder Autorisierungsmiddleware konsistent einsetzen und einen standardmäßigen Deny-Fall vorsehen.
4. Massenzuweisung verhindern: Eigentümer-, Rollen- und Mandantenfelder nicht ungeprüft aus dem Request übernehmen.
5. Indirekte IDs richtig einordnen: UUIDs erschweren Enumeration, ersetzen jedoch keine Prüfung.
6. Überwachen: Viele fehlgeschlagene Objektzugriffe und sequenzielle Abfragen erkennen, ohne sich darauf als Hauptschutz zu verlassen.

Codebeispiel: Objekt global oder im Benutzerkontext laden

Verwundbar:

public function show(string $id)
{
    // Jede existierende Bestellung ist über ihre ID erreichbar
    return Order::findOrFail($id);
}

Sicher über die autorisierte Beziehung:

public function show(Request $request, string $id)
{
    return $request->user()
        ->orders()
        ->whereKey($id)
        ->firstOrFail();
}

Bei komplexeren Regeln lädt Route Model Binding das Objekt und eine Laravel Policy prüft zusätzlich Aktion, Rolle und Mandant. Eine UUID ändert an der notwendigen Autorisierung nichts.

Wie wird IDOR getestet?

Ein belastbarer Test verwendet mindestens zwei Konten mit unterschiedlichen Daten und gegebenenfalls Rollen oder Mandanten. Tester erfassen alle Referenzen und wiederholen Lesen, Ändern und Löschen mit vertauschten IDs, Tokens und Elternobjekten. Sie prüfen auch Batch-Endpunkte, Exporte, mobile APIs und alternative HTTP-Methoden. Automatisierung findet sequenzielle IDs, doch Geschäftsbeziehungen und indirekte Referenzen brauchen meist manuelle Analyse. Produktivdaten werden nur im vereinbarten Umfang abgerufen; ein minimaler Nachweis genügt normalerweise.