IDOR und Broken Access Control: Authentifizierung reicht nicht, Autorisierung ist Pflicht

IDOR (Insecure Direct Object Reference) ist, wenn ein Nutzer mit gültiger Sitzung auf eine Ressource zugreift, die ihm nicht gehört. Das klassische Beispiel: die Nummer in konto?id=1023 auf 1024 ändern, um fremde Rechnungen zu sehen. Der Angreifer knackt kein Passwort und stiehlt keine Sitzung; er ändert nur eine Kennung. IDOR ist das häufigste Mitglied der Familie “Broken Access Control”, die seit Langem die OWASP Top 10 anführt.

Authentifizierung ≠ Autorisierung

Zwei oft verwechselte Konzepte:

• Authentifizierung: “Wer bist du?” — dass der Nutzer angemeldet ist.
• Autorisierung: “Darfst du das tun/sehen?” — dass du Rechte an der angeforderten Ressource hast.

IDOR entsteht, wo die Authentifizierung korrekt, aber die Autorisierung fehlt. Der Nutzer ist angemeldet, doch der Server prüft nicht, ob die angeforderte id ihm wirklich gehört.

Wie es erkannt wird

• Vorhersehbare Kennungen: Fortlaufende numerische IDs (1023 → 1024) laden zur Manipulation ein.
• IDs überall: Nicht nur in der Adresszeile; auch in versteckten Formularfeldern, API-Aufrufen wie PATCH /api/orders/1024 und JSON-Bodies.
• Horizontaler und vertikaler Zugriff: Horizontal (Daten eines gleichwertigen Nutzers) und vertikal (ein normaler Nutzer erreicht eine Admin-Funktion) gehören beide dazu.

Ein praktischer Test: Legen Sie zwei Konten (A und B) an, melden Sie sich als A an und fordern Sie eine Ressourcen-ID von B an. Werden B’s Daten zurückgegeben, existiert IDOR.

Prävention: Autorisierung auf Objektebene

1. Auf dem Server prüfen, anhand des Sitzungsnutzers. Vertrauen Sie der eingehenden id nicht; fragen Sie jedes Mal “gehört diese Bestellung wirklich dem Sitzungsinhaber?”.
2. Die Ressource aus der Sitzung ableiten, wo möglich.
3. Eine zentrale Autorisierungsschicht nutzen; verstreute Prüfungen führen dazu, eine zu vergessen.
4. Unvorhersehbare Kennungen (UUIDs) helfen, genügen aber nicht allein.
5. Standardmäßig ablehnen (default deny).

Zusammenfassung

IDOR ist ein angemeldeter Nutzer, der eine Kennung ändert, um fremde Daten zu erreichen, und die Ursache ist fehlende Autorisierung. Die Lösung ist klar: bei jedem Ressourcenzugriff auf dem Server prüfen, dass der Sitzungsnutzer wirklich berechtigt ist; standardmäßig ablehnen; und die Ressource wo möglich aus der Sitzung ableiten.

Quellen: OWASP: Broken Access Control (A01:2021), OWASP Authorization Cheat Sheet.

Autorisierungsfehler wie IDOR hängen von der Geschäftslogik ab. Das Active-Verification-Paket von CyberTestify führt kontrollierte Autorisierungstests auf erkannten Endpunkten durch.