Gefahr für Web-Anwendungen: Behörden warnen vor IDOR-Schwachstellen

Foto: Kitreel – shutterstock.com

Das Australian Cyber Security Centre (ACSC), die U.S. Cybersecurity and Infrastructure Security Agency (CISA) und die U.S. National Security Agency (NSA) haben gemeinsam eine Cybersecurity-Warnung herausgegeben. Unternehmen sollten demnach Schwachstellen in Web-Anwendungen beseitigen, die sich auf die Zugriffskontrolle beziehen. Hier würden böswillige Akteure im großen Stil Daten manipulieren oder unautorisiert abgreifen.

Die Angreifer verwenden dabei bestimmte Anfragen an Webseiten oder APIs, in denen eindeutige Benutzerkennungen etwa von einem Mitarbeiter oder einem Kunden in eine bestimmte Abfrage oder eine URL integriert ist (fiktives Beispiel: www.hansdampf.de/customer_account?customer_number=12641549). Die Angreifer sind dann erfolgreich, wenn keine angemessenen Authentifizierungs- und Autorisierungsprüfungen vorgenommen werden.

IDOR-Schwachstellen sind weit verbreitet

IDOR-Schwachstellen sind den Behörden zufolge weit verbreitet und lassen sich am besten im Softwareentwicklungs-Prozess unterbinden. Wenn sie einmal vorhanden sind, können sie durch Automatisierung im großen Maßstab missbraucht werden. Den Behörden zufolge sind IDOR-Schwachstellen dafür verantwortlich, dass bereits sensible Daten von Millionen Verbrauchern kompromittiert wurden.

ACSC, CISA und NSA empfehlen Anbietern, Designern und Entwicklern von Web-Anwendungen und entsprechenden Frameworks, streng nach Secure-by-Design-Prinzipien zu entwickeln und sicherzustellen, dass für jede Anfrage, die sensible Daten ändert, löscht oder darauf zugreift, Authentifizierungs- und Autorisierungsprüfungen vorgenommen werden. Auch sollten Devs automatisierte Tools zur Codeüberprüfung verwenden, um IDOR und andere Schwachstellen identifizieren und beheben zu können.

Damit IDs, Namen und Schlüssel nicht in URLs offengelegt werden können, raten die Behörden den Entwicklern, indirekte Referenz-Maps verwenden und diese durch kryptografisch starke, zufällige Werte ersetzen. Auch wird empfohlen, einen Universally Unique Identifier (UUID) oder einen Globally Unique Identifier (GUID) zu verwenden. Natürlich ist auch Sorgfalt bei der Auswahl von Bibliotheken oder Frameworks von Dritten geboten, wenn diese in die eigene Anwendung integriert werden sollen.

Setzen Unternehmen verstärkt auf das Software-as-a-Service-(SaaS)-Modell, sollten sie die Best Practices für das Risikomanagement in der Supply Chain berücksichtigen, Komponenten nur von seriösen Anbietern beziehen und Software-Patches für Web-Anwendungen so schnell wie möglich einspielen. Wer indes auf On-premises-Anwendungen, Infrastructure-as-a-Service (IaaS) und Private-Cloud-Ansätze vertraut, sollte sich anschauen, welche Authentifizierungs- und Autorisierungsprüfungen in Web-Anwendungen verfügbar sind, sofern diese das Ändern und Löschen von sensiblen Daten oder den Zugriff darauf ermöglichen. Hier werden auch regelmäßige, proaktive Schwachstellen-Scans und Penetrationstests empfohlen, um sicherzustellen, dass Internet-fähige Apps und auch die Netzwerkgrenzen sicher sind.

Foto: CISA

Was sind IDOR-Schwachstellen genau?

IDOR-Schwachstellen treten in der Zugriffskontrolle von Webanwendungen und von mobilen Apps auf, wenn diese eine Kennung (ID-Nummer, Name oder einen Key) für den direkten Zugriff auf ein Objekt – etwa einen Datensatz in einer Datenbank – verwendet, dabei aber die Authentifizierung oder Autorisierung des Benutzers, der die Anfrage stellt, nicht ordnungsgemäß überprüft. Je nach Art der Schwachstelle können böswillige Akteure darüber auf sensible Daten zugreifen, Objekte ändern oder löschen oder auf Funktionen zugreifen.

Unterschieden wird zwischen horizontalen und vertikalen IDOR-Schwachstellen. Erstere treten auf, wenn ein Benutzer unerlaubt auf Daten derselben Berechtigungsstufe zugreifen kann – zum Beispiel auf die Daten anderer Benutzer. Von vertikalen IDOR-Schwachstellen ist die Rede, wenn unautorisierte User auf Daten einer höheren Berechtigungsstufe zugreifen können. Außerdem gibt es IDOR-Schwachstellen auf Objektebene, die auftreten, wenn Nutzer unautorisiert Objekte ändern oder löschen können, sowie solche auf Funktionsebene, wo User eine Aktion starten können, zu der sie nicht berechtigt sind.

Die Schwachstellen entstehen immer dann, wenn ein Object Identifier offengelegt oder extern weitergegeben wird, oder weil er leicht zu erraten ist. Unautorisierte Benutzer verwenden dann diesen Bezeichner oder ändern ihn. Sie ändern etwa die HTML-Daten im Body einer Post-Anforderung, um bestimmte Datensätze anzusprechen (Body Manipulation), oder sie manipulieren zu diesem Zwecke einen Bezeichner in einem Link (URL Tampering).

Möglich ist auch, dass ein Bezeichner in einem Cookie verändert wird, um auf den Account eines anderen, gerne auch eines Admins, zuzugreifen (Cookie ID Manipulation). Last-but not least gibt es das HTTP/JSON Request Tampering, bei dem ein Akteur einen Web-Proxy verwendet, um Teile legitimer Anfragen abzufangen und zu verändern.

All diese Schwachstellen sind weit verbreitet und ließen sich im Entwicklungsprozess wirksam verhindern. Die drei Sicherheitsorganisationen warnen davor, dass böswillige Akteure entsprechende Sicherheitslücken automatisiert und in großem Umfang erkennen und ausnutzen können. (hv)