Was ist IDOR und wie schützt man sich?
Autor: Redaktion Domeny.ForSale Veröffentlicht
Kurz gesagt: IDOR (Insecure Direct Object Reference) ist eine Sicherheitslücke, bei der eine Anwendung den Zugriff auf fremde Ressourcen über deren Kennung erlaubt, ohne die Berechtigungen ausreichend zu prüfen. Beispielsweise ändert ein Benutzer die Rechnungsnummer in der Adresse und sieht daraufhin das Dokument eines anderen Kunden. Das Problem ist nicht die Nummer in der Adresse, sondern dass der Server nicht prüft, ob diese Person auf die Rechnung zugreifen darf.
Wie IDOR funktioniert – ein einfaches Beispiel
Stell dir ein Kundenportal vor, in dem du nach der Anmeldung deine eigene Rechnung herunterlädst. Der Browser sendet eine Anfrage für den Pfad /rechnungen/481 an den Server, und die Anwendung liefert das Dokument mit der Nummer 481 zurück.
Eine solche Adresse ist an sich eine übliche Lösung. Die Sicherheitslücke entsteht, wenn du den Pfad auf /rechnungen/482 ändern und dadurch die Rechnung eines anderen Kunden herunterladen kannst, obwohl dir kein Zugriff darauf gewährt wurde.
Das ist wie eine Garderobe, an der ein Mitarbeiter jedem einen Mantel aushändigt, der die Nummer des Kleiderbügels nennt, statt die Abholberechtigung zu prüfen. Die Nummer bezeichnet den Gegenstand, bestätigt aber nicht das Recht, ihn zu erhalten.
„Objekt“ steht im Namen IDOR für eine Ressource der Anwendung: ein Dokument, eine Bestellung, ein Foto, eine Nachricht oder ein Konto. „Direkte Referenz“ bedeutet, dass diese Ressource über eine Kennung angesprochen wird. Das muss keine fortlaufende Zahl sein – auch ein Dateiname, eine E-Mail-Adresse oder eine lange Zeichenfolge kann als Kennung dienen.
Warum die Anmeldung allein nicht genügt
Authentifizierung beantwortet die Frage: „Wer bist du?“ Autorisierung, also die Prüfung der Berechtigungen, beantwortet eine andere Frage: „Was darfst du tun?“ Eine Anwendung kann den angemeldeten Benutzer korrekt erkennen und ihm dennoch fremde Daten zugänglich machen.
Ein sicherer Server sollte nicht nur prüfen, ob die Rechnung existiert, sondern auch, ob der Benutzer sie lesen darf. Eine Zugriffsberechtigung kann sich daraus ergeben, dass ihm das Dokument gehört, dass er eine bestimmte Rolle in der Organisation hat oder dass das Dokument gezielt für ihn freigegeben wurde.
IDOR beschränkt sich nicht auf das Einsehen von Informationen. Fehlende Prüfungen können auch ermöglichen, fremde Ressourcen zu ändern oder zu löschen, beispielsweise die Lieferadresse einer Bestellung. Eine Leseberechtigung bedeutet nicht automatisch, dass auch Änderungen erlaubt sind. Deshalb muss jede Aktion entsprechend geprüft werden.
Wenn eine Anwendung mehrere Unternehmen bedient, sind auch die Grenzen zwischen den Organisationen wichtig. Ein Administrator eines Unternehmens sollte nicht auf die Daten eines anderen zugreifen können, nur weil er die Kennung eines dortigen Dokuments kennt.
Wo sich eine angreifbare Kennung verbergen kann
Die Kennung muss nicht in der Adressleiste sichtbar sein. Sie kann in Abfrageparametern, im Inhalt einer von einem Formular gesendeten Anfrage oder in einem Aufruf einer API stehen, also einer Schnittstelle zur Kommunikation zwischen Programmen.
Typische Vorgänge, bei denen Berechtigungen geprüft werden müssen, sind:
- das Herunterladen von Rechnungen, Anhängen und Datenexporten;
- das Lesen von Nachrichten, Anfragen und Bestellungen;
- das Aktualisieren des Profils oder der Kontoeinstellungen;
- das Löschen von Dateien und anderen Ressourcen.
Nicht jeder Zugriff nach dem Ändern einer Kennung ist ein Fehler. Ein öffentlicher Blogbeitrag sollte für alle zugänglich sein, ein gemeinsam genutztes Dokument für die berechtigten Mitarbeiter. Entscheidend für eine Sicherheitslücke ist, ob die vorgesehenen Zugriffsregeln verletzt werden – nicht allein die Möglichkeit, ein anderes Objekt anzusprechen.
Ähnliche Fehler in einer API werden auch als BOLA (Broken Object Level Authorization) bezeichnet, also als fehlerhafte Berechtigungsprüfung auf Ebene eines bestimmten Objekts. Die Begriffe sind eng miteinander verbunden. Die praktische Frage bleibt dieselbe: Prüft der Server, ob der Benutzer auf die angegebene Ressource zugreifen und die gewünschte Aktion ausführen darf?
Was wirklich vor IDOR schützt
Die grundlegende Schutzmaßnahme ist eine serverseitige Berechtigungsprüfung bei jedem Zugriff auf eine Ressource. Eine Schaltfläche in der Benutzeroberfläche auszublenden, genügt nicht, denn die Anfrage lässt sich auch ohne diese Schaltfläche senden.
Im Rechnungsbeispiel sollte die Anwendung das Dokument nur unter den für den jeweiligen Benutzer zugänglichen Dokumenten suchen oder vor der Ausgabe die Berechtigungen prüfen. Ein vom Browser übermitteltes Feld „Eigentümer“ sollte sie nicht als Nachweis dafür akzeptieren, wem das Dokument gehört.
Zufällige Kennungen wie UUID erschweren das Erraten von Adressen, ersetzen aber keine Autorisierung. Wird eine Kennung bekannt, etwa über einen geteilten Link, muss der Server einer unberechtigten Person den Zugriff weiterhin verweigern.
Ein guter Grundsatz ist die standardmäßige Verweigerung: Kann die Anwendung die Berechtigung für eine Aktion nicht bestätigen, führt sie diese nicht aus. Die Prüfung sollte auch Dateidownloads und Exporte umfassen, nicht nur die Hauptansicht des Dokuments.
So prüfst du deine eigene Anwendung sicher
Führe einen solchen Test ausschließlich in einem System durch, das dir gehört oder für dessen Prüfung du eine Erlaubnis hast. Verwende am besten eine Testumgebung und fiktive Daten, besonders beim Ändern und Löschen.
- Erstelle zwei Testkonten: A und B, ohne gegenseitig freigegebene Ressourcen.
- Erstelle mit Konto A ein Dokument und notiere dessen Kennung.
- Melde dich als B an und versuche, das Dokument über die vorgesehene Benutzeroberfläche oder die API zu lesen.
- Prüfe gesondert, ob du es bearbeiten, herunterladen oder löschen kannst, sofern diese Aktionen angeboten werden.
- Prüfe nicht nur, ob eine Ablehnung angezeigt wird, sondern auch, ob tatsächlich keine Daten offengelegt oder verändert wurden.
Der Server sollte die unzulässige Aktion verweigern. Er kann dabei auch bewusst verbergen, ob das Dokument überhaupt existiert. Es lohnt sich, dieses Szenario in automatisierte Tests aufzunehmen, damit eine Codeänderung die Sicherheitslücke nicht erneut öffnet.
Siehe auch: Was ist 2FA?
Lesen Sie auch
