Coders Conquer Security: Share & Learn-Reihe: Insecure Direct Object Reference

URLs sind für die Navigation auf allen Websites und Webanwendungen, die wir kennen und nutzen, unverzichtbar. Ihre grundlegende Funktion besteht darin, Ressourcen zu identifizieren und deren Abruf zu ermöglichen. Obwohl URLs für das World Wide Web essenziell sind, können sie bei mangelnder Absicherung ein Sicherheitsrisiko darstellen.

In diesem Beitrag erfahren Sie:

• Was IDOR ist und wie Angreifer es nutzen
• Warum IDOR gefährlich ist
• Techniken zur Behebung dieser Schwachstelle

IDOR verstehen

Eine direkte Objekt-Referenz liegt vor, wenn ein bestimmter Datensatz (das „Objekt“) innerhalb einer Anwendung referenziert wird. Dies geschieht meist über eine eindeutige Kennung, die häufig in der URL erscheint.

Sie haben vielleicht schon einmal ein „?id=12345“ am Ende einer URL bemerkt. Die Zahl 12345 ist dabei die Referenz auf einen spezifischen Datensatz. Sicherheitslücken entstehen, wenn für einzelne Datensätze keine Zugriffskontrolle implementiert ist. Dies ermöglicht es Benutzern, auf Daten zuzugreifen, die sie eigentlich nicht sehen dürften. Ein solcher Angriff erfordert nur geringe technische Kenntnisse.

Angenommen, ein Angreifer ändert in diesem Fall die ID in der URL auf 12344. In einer Anwendung, die anfällig für IDOR ist, könnte der Angreifer nun die Daten einsehen, die zu diesem Datensatz gehören.

Wie groß ist der Schaden, den eine solche Schwachstelle tatsächlich anrichten kann?

Warum IDOR gefährlich ist

Wenn Entwickler nicht sorgfältig arbeiten, können sie ein System entwerfen, das Anwendungsdaten an verschiedenen Stellen preisgibt. Ein solcher Datenleck-Vorfall kann schwerwiegende Folgen haben, insbesondere wenn sensible Informationen oder personenbezogene Daten (PII) betroffen sind.

Das australische Finanzamt richtete eine Website ein, um Unternehmen bei der Erhebung einer neuen Steuer zu unterstützen. Leider enthielt sie eine ungewollte IDOR-Schwachstelle. Ein neugieriger Nutzer stellte fest, dass die URLs der Website seine australische Unternehmensnummer (ABN) enthielten. Da diese Nummer für jedes registrierte Unternehmen leicht herauszufinden ist, probierte der Nutzer einfach die Nummern anderer Firmen in der URL aus. Er erhielt daraufhin Zugriff auf deren Bankverbindungen und persönliche Daten!

Auch Apple wurde kürzlich Opfer einer IDOR-Schwachstelle. Bei der Einführung des iPads wurden 114.000 E-Mail-Adressen von Kunden geleakt. (Fairerweise muss man sagen, dass dies eher ein Fehler von AT&T war).

AT&T hatte einen Dienst zur Unterstützung der 3G-Konnektivität für iPads entwickelt. Das iPad übermittelte eine auf der SIM-Karte gespeicherte Kennung an den Dienst von AT&T, welcher daraufhin die E-Mail-Adresse des Nutzers zurückgab.

Leider handelte es sich bei diesen Kennungen um einfache fortlaufende Zahlen, die leicht zu erraten waren. Angreifer konnten die Kennungen durchlaufen und so die E-Mail-Adressen stehlen.

Ein weiterer Fehler bestand darin, dass der Dienst von AT&T versuchte, sich abzusichern, indem er die E-Mail-Adresse nur dann zurückgab, wenn der User-Agent-Header der Anfrage signalisierte, dass sie von einem iPad stammte. Der User-Agent ist jedoch nur ein String-Wert, der leicht manipuliert werden kann.

IDOR-Schwachstellen können subtil und tückisch sein. Lassen Sie uns besprechen, wie man sie effektiv verhindert.

IDOR besiegen

Zugriffskontrolle ist der Schlüssel zur Lösung von IDOR. Stellen Sie bei jeder Anfrage eines Benutzers nach einem bestimmten Datensatz sicher, dass dieser auch dazu berechtigt ist.

Am besten gelingt dies durch den Einsatz zentraler Autorisierungsmodule. Tools wie Spring Security bieten robuste und anpassbare Authentifizierungs- und Autorisierungsfunktionen für Anwendungen.

Kurz gesagt: Nutzen Sie ein zentrales Modul, auf das sich der gesamte restliche Code für Autorisierungsprüfungen stützt.

Eine weitere gängige Schutzmaßnahme ist die Verwendung von Ersatzreferenzen. Anstatt die tatsächlichen Datenbank-IDs in Ihren URLs zu verwenden, können Sie Zufallszahlen generieren, die auf die entsprechenden Datensätze verweisen.

Durch die Verwendung von Ersatzreferenzen verhindern Sie, dass ein Angreifer durch einfaches Raten der nächsten gültigen ID auf einen Datensatz zugreifen kann.

Verlassen Sie sich schließlich niemals auf Daten, die vom Benutzer manipuliert werden können, um Autorisierungen vorzunehmen. AT&T versuchte, den User-Agent-Header zur Autorisierung zu nutzen. Vertrauen Sie nicht auf HTTP-Header, Cookies oder GET- und POST-Parameter.

Mit diesen Schutzmaßnahmen gehört IDOR der Vergangenheit an.

Sichern Sie Ihre Referenzen

Unsichere direkte Objektverweise gehören zu den am einfachsten auszunutzenden Schwachstellen. Lassen Sie sich nicht unvorbereitet erwischen. Prüfen Sie immer die Benutzerberechtigungen, verwenden Sie keine echten Datenbank-IDs und verlassen Sie sich bei der Autorisierung nicht auf benutzergesteuerte Daten.

Vertiefen Sie Ihr Wissen mit unseren Lernressourcen. Wenn Sie üben, wie man IDOR-Schwachstellen in der Sprache Ihrer Wahl entschärft, werden Sie diese Probleme in Ihren Produktions-Codebases problemlos finden und beheben können. Testen Sie Ihr neues Verteidigungswissen mit einer kostenlosen Demo der Secure Code Warrior-Plattform, die Cybersicherheitsteams zu echten Cyber-Experten ausbildet. Mehr über die Abwehr dieser und vieler anderer Bedrohungen erfahren Sie im Secure Code Warrior-Blog.

Bereit, sich gegen IDOR-Angriffe zu wehren? Besuchen Sie unsere Plattform und fordern Sie sich kostenlos heraus: [Hier starten]