Teil 1 – Was ist IDOR?

Ein Hotel mit einem falschen Schlüsselprinzip

Stell dir vor, du gehst in ein Hotel, und jede Zimmertür hat denselben Schlüssel. Dein Schlüssel für Zimmer 101 öffnet plötzlich auch 102, 103 und 104. Klingt absurd? Genau das passiert im Internet häufiger, als man denkt – und es hat sogar einen Namen: Insecure Direct Object Reference (IDOR).

Die eigentliche Schwachstelle

Bei einer IDOR-Schwachstelle erlaubt eine Webanwendung den Zugriff auf Objekte, nur weil der Benutzer den „Zeiger“ auf dieses Objekt kennt. Ein „Objekt“ kann vieles sein: ein Benutzerprofil, eine Bestellung, ein Dokument oder sogar ein Support-Ticket.
Das Problem entsteht, wenn die Anwendung nicht prüft, ob der anfragende Nutzer auch wirklich berechtigt ist, dieses Objekt zu sehen.

Einfache URL-Manipulation

Ein klassisches Beispiel sieht man direkt in der URL:

https://shop.example.com/order?id=1001

Als eingeloggter Kunde kannst du deine eigene Bestellung mit der ID 1001 ansehen. Aber was passiert, wenn du in der URL die Zahl änderst – etwa auf 1002?

https://shop.example.com/order?id=1002

Wenn die Anwendung hier keinen Autorisierungs-Check durchführt, könntest du plötzlich die Bestellung eines anderen Kunden einsehen. Vielleicht sind es nur harmlose Bestellnummern, vielleicht aber auch sensible Daten wie Adresse, Zahlungsinformationen oder Kundennamen.

IDOR bei APIs

Dasselbe Problem tritt oft auch bei APIs auf. Ein Beispiel-Request könnte so aussehen:

GET /api/v1/user/42 HTTP/1.1
Host: app.example.com
Authorization: Bearer eyJhbGciOi...

Wenn die API nur prüft, ob der Nutzer eingeloggt ist, nicht aber, ob er wirklich User 42 ist, kann er durch einfache Manipulation auch Daten von User 43 oder 44 abrufen.

Warum passiert das so oft?

Der Hauptgrund ist, dass Entwickler*innen häufig den Fokus auf Authentifizierung (ist der Nutzer eingeloggt?) legen, aber nicht auf Autorisierung (darf er dieses spezielle Objekt sehen oder bearbeiten?). Es ist also kein technischer „Bug“ im klassischen Sinne, sondern eher ein Designfehler in der Zugriffskontrolle.

Gefährlich, weil simpel

IDOR-Schwachstellen sind so gefährlich, weil sie extrem leicht auszunutzen sind. Es braucht kein spezielles Hacking-Tool – oft reicht es, eine Zahl in der URL zu verändern oder ein Feld im Formular zu manipulieren. Genau deshalb tauchen IDORs regelmäßig in den OWASP Top 10 auf, also in der Liste der kritischsten Web-Sicherheitslücken weltweit.

Was du mitnehmen solltest

IDOR bedeutet, dass Nutzer Zugriff auf Daten oder Funktionen bekommen, die ihnen gar nicht gehören, nur weil die Anwendung den Verweis auf das Objekt nicht absichert. In den nächsten Teilen dieser Serie schauen wir uns an, wie man solche Schwachstellen erkennt, wie Angreifer vorgehen und – besonders wichtig – wie man sich als Entwickler davor schützen kann.