IDOR (Insecure Direct Object Reference)
IDOR erlaubt Zugriff auf fremde Objekte durch Manipulation von IDs in URLs/Requests. Beispiel: /user/profile?id=123 auf id=124 ändern zeigt fremdes Profil. Fehler: Fehlende Authorization-Checks.
detaillierte erklärung
Insecure Direct Object Reference (IDOR) ist eine Broken Access Control-Schwachstelle (OWASP #1), bei der die Anwendung direkte Referenzen auf interne Objekte (Datei, Datenbankzeile, User) in URLs/Parameters preisgibt, ohne Authorization zu prüfen. Beispiel: /api/invoice/1337 lädt Invoice mit ID 1337. Angreifer testet /api/invoice/1338 und erhält fremde Rechnung, da App nur prüft "ist User eingeloggt?", nicht "darf User Invoice 1338 sehen?". Varianten: Numerische IDs (einfach durchzählen), UUIDs (schwerer, aber oft in Responses geleakt), Dateinamen (../../../etc/passwd via Path-Traversal). Konsequenzen: Datenlecks (PII, Finanzdaten), Privilege-Escalation (/api/admin/delete?id=5 als normaler User), Account-Takeover (Password-Reset-Token eines anderen Users verwenden). Schutzmaßnahmen: Authorization-Checks bei JEDEM Request ("Darf dieser User auf dieses Objekt zugreifen?"), indirekte Referenzen (Session-basierte Mappings statt direkte IDs), UUIDs statt Sequential IDs (kein Durchzählen).
warum ist das wichtig?
IDOR ist eine der häufigsten Web-Schwachstellen und Basis vieler Bug-Bounty-Reports - du musst verstehen, dass Authentication ≠ Authorization. Essentiell für Pentesting (Parameter-Fuzzing mit Burp Intruder) und Secure Development.
häufige fehler
- ⚠Eingeloggt = autorisiert - Nein, Login prüft nur Identität, nicht Zugriffsberechtigung
- ⚠UUIDs machen IDOR unmöglich - Nein, UUIDs werden oft in Responses geleakt, dann gleich angreifbar
- ⚠Nur GET-Requests sind anfällig - Nein, auch POST/PUT/DELETE (DELETE /api/user/1234 als normaler User)