Insecure Direct Object Reference (IDOR)

Eine Insecure Direct Object Reference (IDOR) ist ein Klassiker unter den Schwachstellen in Webanwendungen und APIs: technisch simpel, weit verbreitet und in den Folgen oft schmerzhaft. Die Anwendung lässt Nutzer über eine ID direkt auf Objekte verweisen (Rechnungen, Akten, Fotos), prüft aber nicht, ob der Anfragende dieses Objekt überhaupt sehen darf. Wer die ID verändert, blickt in fremde Daten.

Was ist eine Insecure Direct Object Reference?

Eine IDOR entsteht, wenn eine Anwendung eine interne Referenz (meist eine Datenbank-ID, manchmal ein Dateiname oder eine Kundennummer) direkt in die URL, ein Formular oder einen API-Request schreibt und den Zugriff anschließend nur daran festmacht, ob jemand angemeldet ist, statt daran, ob dieser Nutzer dieses konkrete Objekt verwenden darf. Die Authentifizierung funktioniert, die Autorisierung auf Objektebene fehlt.

Ein Bild aus dem Alltag: eine Garderobe ohne Kontrolle. Wer Nummer 87 ruft, bekommt Mantel 87 ausgehändigt, auch mit der Marke 12 in der Hand. Der Mitarbeiter prüft zwar, dass Sie überhaupt eine Garderobenmarke besitzen (Authentifizierung), aber nicht, ob die Marke zum Mantel gehört (Autorisierung).

In der OWASP Top 10 fällt IDOR unter A01:2021 (Broken Access Control), die am weitesten verbreitete Kategorie von Schwachstellen. Im API-Umfeld ist für dasselbe Problem der Begriff BOLA gebräuchlich: Broken Object Level Authorization. MITRE führt es als CWE-639, “Authorization Bypass Through User-Controlled Key”.

Wie funktioniert ein IDOR-Angriff?

Ein Angreifer braucht meist nicht mehr als ein eigenes, legitimes Konto. Damit beobachtet er, wie die Anwendung Objekte adressiert, etwa GET /api/invoices/1042 für die eigene Rechnung. Anschließend ändert er die Nummer auf 1043, 1044 und so weiter. Liefert der Server statt einer Fehlermeldung fremde Rechnungen aus, ist die IDOR bestätigt. Mit einem kleinen Skript lassen sich so tausende Objekte pro Stunde abgreifen, vor allem bei fortlaufenden, vorhersagbaren IDs.

Die verwundbare Referenz muss nicht im URL-Pfad stehen. Auch Query-Parameter, versteckte Formularfelder, JSON-Felder im POST-Body, Cookies und Dateinamen von Downloads sind beliebte Fundorte. Und es bleibt nicht beim Lesen: Derselbe Fehler in einem Update- oder Delete-Endpunkt erlaubt es, fremde Daten zu ändern oder zu löschen.

Ein konkretes Beispiel aus einer Node.js/Express-API:

Verwundbar:

// GET /api/invoices/:id
app.get("/api/invoices/:id", requireLogin, async (req, res) => {
  // Lädt die Rechnung aus der URL - egal, wem sie gehört
  const invoice = await db.invoices.findById(req.params.id);
  if (!invoice) return res.status(404).end();
  res.json(invoice);
});

Die Middleware requireLogin stellt zwar sicher, dass eine Session existiert, doch die Abfrage lädt danach jede beliebige ID. Die sichere Variante bindet die Suche an den angemeldeten Nutzer:

Sicher:

// GET /api/invoices/:id
app.get("/api/invoices/:id", requireLogin, async (req, res) => {
  // Nur innerhalb der Rechnungen des angemeldeten Nutzers suchen
  const invoice = await db.invoices.findOne({
    id: req.params.id,
    ownerId: req.user.id,
  });
  if (!invoice) return res.status(404).end();
  res.json(invoice);
});

Existiert die Rechnung, gehört aber jemand anderem, erhält der Anfragende jetzt dieselbe 404-Antwort wie bei einer nicht existierenden ID. Es sickert also nicht einmal durch, welche Nummern vergeben sind. Dieselbe Prüfung gehört in jeden Endpunkt, der Objekte liest, ändert oder löscht.

Welche Auswirkungen hat eine IDOR-Schwachstelle?

Schon reiner Lesezugriff wiegt schwer: Personendaten, Rechnungen, Patientenakten oder Verträge liegen offen. Da IDs häufig fortlaufend vergeben werden, skaliert ein solches Leck mühelos vom einzelnen Datensatz zur kompletten Datenbank. Für Organisationen, die personenbezogene Daten verarbeiten, wird daraus schnell ein meldepflichtiger Vorfall nach DSGVO, inklusive Aufsichtsbehörde, Kundenkommunikation und Reputationsschaden. Das bekannteste Beispiel ist der US-Titelversicherer First American: 2019 waren dort rund 885 Millionen Dokumente mit Hypotheken- und Personendaten über fortlaufende Dokumentnummern frei abrufbar.

Mit Schreibzugriff wird es gravierender. Wer fremde Profile bearbeiten kann, ändert beispielsweise die E-Mail-Adresse eines Opfers und übernimmt das Konto anschließend per Passwort-Reset. IDOR ist damit ein beliebtes Sprungbrett zur vollständigen Kontoübernahme und zu Betrug.

Fachlich unterscheidet man horizontale Eskalation (Zugriff auf Daten gleichgestellter Nutzer) und vertikale Eskalation (Zugriff auf Admin-Funktionen). IDOR-Befunde werden deshalb in der Regel als medium bis high eingestuft, je nach Sensibilität der Daten und danach, ob auch geschrieben werden kann.

Wie lässt sich IDOR aufspüren?

Automatisierte Scanner finden IDOR selten zuverlässig: Ein Scanner weiß nicht, welches Objekt zu welchem Nutzer gehört, und eine gültige Antwort sieht für ein Tool genauso aus wie ein Leck. IDOR aufzuspüren ist deshalb vor allem Handarbeit:

• Testen Sie mit zwei (oder mehr) Konten: Führen Sie jede Aktion als Nutzer A aus und wiederholen Sie den Request mit der Session von Nutzer B und den IDs von A.
• Gehen Sie systematisch alle Objektreferenzen durch: URL-Pfade, Query-Parameter, POST-Bodies, versteckte Felder, Export- und Download-Links.
• Nutzen Sie Werkzeuge wie Burp Suite (Repeater oder die Erweiterung Autorize), um Requests mit vertauschten Sessions erneut zu senden.
• Achten Sie auch auf indirekte Wege: Reports, PDF-Generatoren, Such-Endpunkte und alte API-Versionen vergessen die Prüfung auffallend oft.

Bei einem Pentest von AssistSec gehört genau das zum Standardprogramm: Jede Objektreferenz wird mit mehreren Testkonten nachgestellt, gerade weil diese Fehlerklasse automatisierten Tools entgeht. Auch im laufenden Betrieb ist Erkennung möglich: Serien von 403- oder 404-Antworten auf fortlaufende IDs im Log deuten auf Enumeration hin.

Wie verhindern Sie IDOR?

Die Abhilfe ist konzeptionell einfach: Prüfen Sie bei jedem Objektzugriff serverseitig, ob der Anfragende genau dieses Objekt verwenden darf.

• Erzwingen Sie Autorisierung auf Objektebene bei jedem Lese-, Schreib- und Löschvorgang, nie nur beim Login.
• Binden Sie Datenbankabfragen standardmäßig an Eigentümer oder Mandanten (ownerId, Organisations-ID), wie im Beispiel oben.
• Zentralisieren Sie die Prüfung in Middleware oder Policy-Klassen, damit eine vergessene Abfrage in einem Endpunkt nicht sofort zum Leck wird.
• Arbeiten Sie nach dem Prinzip deny by default: Ohne explizite Berechtigung kein Zugriff, beantwortet mit einer neutralen 404.
• Ersetzen Sie vorhersagbare, fortlaufende IDs wo möglich durch unvorhersagbare (UUIDs), als zusätzliche Hürde.
• Nehmen Sie Multi-User-Tests in die CI auf: Ein Integrationstest, der mit Konto B die Objekte von Konto A anfragt, verhindert Regressionen.
• Machen Sie Autorisierung zum festen Punkt jedes Code-Reviews für neue Endpunkte.