Definition
IDOR steht für Insecure Direct Object Reference und bezeichnet eine Sicherheitslücke in Webanwendungen und APIs. Dabei handelt es sich um eine Schwachstelle, bei der ein Angreifer durch Manipulation von Referenzen auf Objekte direkt auf Ressourcen zugreifen kann, die eigentlich geschützt sein sollten. Die Referenzen sind meist einfache Identifikatoren wie IDs, Dateinamen oder Schlüssel, die in URLs oder Formularen übermittelt werden.
Die Sicherheitslücke entsteht, wenn keine ausreichende Zugriffskontrolle auf der Serverseite implementiert ist. Das bedeutet, dass die Anwendung nicht prüft, ob der anfragende Nutzer berechtigt ist, auf die angeforderte Ressource zuzugreifen. Durch das Ändern der ID in der Anfrage kann ein Angreifer somit Daten anderer Nutzer einsehen, verändern oder löschen.
Was bedeutet das für Ihr Unternehmen?
IDOR-Lücken gehören zu den häufigsten Schwachstellen in Kundenportalen: Wer in der Adresse eine Rechnungs- oder Auftragsnummer ändert, sieht plötzlich Daten eines anderen Kunden. Für Ihr Unternehmen wäre das ein meldepflichtiger Datenschutzvorfall. Bei Anwendungen mit Kundenkonten sollte deshalb jeder Zugriff serverseitig prüfen, ob das Objekt dem angemeldeten Nutzer gehört, und ein Penetrationstest gezielt danach suchen.
Hintergrund und Entstehung
IDOR ist eine Form von Broken Access Control, einer der häufigsten Schwachstellen in Webanwendungen. Der Begriff wurde im Rahmen der OWASP Top Ten Sicherheitsrisiken bekannt, wobei IDOR typischerweise unter dem Punkt „Broken Access Control“ gelistet wird. Die Problematik besteht darin, dass Entwickler oft auf Client-seitige Validierungen vertrauen oder keine feingranulare Zugriffskontrolle auf Objektebene implementieren.
Die Schwachstelle ist besonders verbreitet in Anwendungen, die Ressourcen über einfache, inkrementelle oder vorhersehbare Identifikatoren adressieren. Beispiele sind Benutzerprofile, Rechnungen, Dokumente oder Bilder, die über eine ID in der URL aufgerufen werden. Ohne serverseitige Prüfung kann ein Angreifer diese IDs systematisch durchprobieren (Insecure Direct Object Reference Enumeration) und so unautorisierten Zugriff erlangen.
Funktionsweise
Bei einer IDOR-Schwachstelle übermittelt der Client eine Referenz zu einer Ressource, beispielsweise eine Kundennummer oder eine Bestell-ID. Die Anwendung prüft jedoch nicht, ob der Nutzer berechtigt ist, diese Ressource einzusehen oder zu bearbeiten. Dadurch kann ein Angreifer die ID verändern, um auf andere Ressourcen zuzugreifen.
Die Manipulation erfolgt typischerweise durch Modifikation von URL-Parametern, Formularfeldern oder API-Anfragen. Da die Referenzen oft einfach aufgebaut sind, lassen sie sich leicht erraten oder durch systematisches Ausprobieren ermitteln. Die fehlende oder unzureichende Autorisierung auf der Serverseite erlaubt so den Zugriff auf fremde Daten.
Beispiele und Einsatzgebiete
IDOR-Schwachstellen treten häufig in webbasierten Anwendungen auf, die Benutzerdaten, Dokumente oder Transaktionen verwalten. Beispielsweise kann ein Online-Shop durch IDOR auf Bestellungen anderer Kunden zugreifen lassen oder ein soziales Netzwerk private Nachrichten offenlegen.
Auch bei APIs, die mobile Apps oder Single-Page-Applications mit Daten versorgen, ist IDOR ein verbreitetes Problem. Hier können Angreifer durch Manipulation von API-Parametern auf geschützte Ressourcen zugreifen, wenn keine ausreichende Zugriffskontrolle implementiert ist.
Abgrenzung zu ähnlichen Sicherheitslücken
IDOR unterscheidet sich von anderen Zugriffskontrollproblemen durch die direkte Manipulation von Objektreferenzen. Im Gegensatz zu Cross-Site Scripting (XSS) oder SQL-Injection zielt IDOR nicht auf die Ausnutzung von Code-Injektionen ab, sondern auf fehlende Autorisierung bei der Ressourcenanfrage.
Eine verwandte Schwachstelle ist die Broken Access Control allgemein, unter die IDOR fällt. Während Broken Access Control auch andere Formen der Umgehung von Zugriffsrechten umfasst, fokussiert sich IDOR speziell auf die unsichere Handhabung von direkten Objektreferenzen.