IDOR – Wie Hacker an geheime Informationen kommen

Sogenannte „Insecure Direct Object Reference“-Schwachstellen stellen eine große Bedrohung für Webanwendungen dar. Diese Art von Schwachstellen ermöglicht es Zugriffskontrollen in Webapplikationen zu umgehen. Wie genau das möglich ist, und vor allem wie das zu verhindern ist, erklärt dieser Beitrag. 

IDOR: Wenig Buchstaben, großer Schaden

Insecure Direct Object Reference, kurz IDOR, ist eine Art von Schwachstellen in Webanwendungen. IDORs treten auf, wenn Parameter zur Zugriffskontrolle, die vom Nutzer in Web-Request mitgesendet werden, nicht auf deren Richtigkeit überprüft sind. Diese Parameter können in einer URL, in einem Cookie oder POST-Body Daten vorkommen. Nehmen wir folgendes Beispiel an: Eine Bank betreibt eine Webseite mit Registrierungs- und Login-Funktion. Loggt sich ein Nutzer ein, wird er auf seine Home-Seite geleitet. Der Server weiß über die mitgegebene ID, welche Seite er welchem Nutzer zuordnen muss. Je nach ID sehen die Nutzer jeweils ihren Account.

https://bankseite.com/home?id=16

Angezeigt werden in unserem Beispiel nur der Nutzername und der Kontostand. Der Nutzer kann Geld senden, neue Nachrichten anschauen oder sich wieder ausloggen.

Eine eigentlich einfache Möglichkeit, um die Nutzerdaten im Hintergrund zu verwalten. Über die mitgesendete ID kann der Server die Daten des Benutzers in der Datenbank abfragen und wieder an diesen zurückgeben. Wo ist jetzt die Schwachstelle?

Das Problem in diesem Beispiel ist die fehlende Überprüfung der ID. Es ist nicht sichergestellt, dass die Person, welche die ID sendet, auch tatsächlich die Person ist, zu der die ID gehört. Ein Angreifer kann somit den ID-Parameter in der URL ändern, um Daten von anderen Nutzern zu sehen. Das System geht also davon aus, dass die ID, die es gesendet bekommt, bereits validiert ist. Bei dieser Art von Validierung des Nutzers, spricht man von Client-seitiger Authentifizierung.

https://bankseite.com/home?id=15

https://bankseite.com/home?id=17

Schild aktivieren: Schutz vor IDORs

IDORs entstehen also durch unzureichende Zugriffskontrolle. Rein Client-seitige Validierung der Nutzeridentität ist also nicht genug. Um sicherzustellen, dass nur berechtigte Nutzer auf ihre Daten zugreifen können, muss diese Überprüfung auch auf der Serverseite stattfinden. Jede Request, die sensible Daten anfordert, muss vom Server auf Richtigkeit kontrolliert werden. Richtigkeit bedeutet, sicherzustellen, dass der Nutzer, welcher die Request sendet, auch tatsächlich der Nutzer ist, der diese Request senden darf. Der Client, in unserem Beispiel der Nutzer, hat also eine Bringschuld gegenüber des Servers. Er muss nachweisen, dass er wirklich der richtige Nutzer ist.

Praktisch kann dieses Problem mit Cookies gelöst werden. In einem Cookie kann dann beispielsweise eine verschlüsselte Nutzer-ID gespeichert werden. Der Server entschlüsselt beim Erhalt der Request den Cookie und sendet die Daten, passend zu der entschlüsselten ID, zurück. Solange nur der Server den Schlüssel kennt, können Nutzer nur auf die Daten zugreifen, zu denen sie auch den passenden Cookie haben, eben ihren eigenen.

Betrachtung mit Compliance-Brille: Auswirkungen und Risiko

Risikobetrachtungen erfolgen in der Regel anhand verletzter Schutzziele, bzw. anhand von Schutzziele, die durch das Ausnutzen der Schwachstelle verletzt werden. Probleme, die durch IDORs entstehen, sind große Datenleaks, die nicht nur der Reputation des betroffenen Unternehmens schaden, sondern auch die persönlichen Daten der Endnutzer in Gefahr bringen. Eine IDOR-Schwachstelle erlaubt Zugang zu persönlichen und sensitiven Informationen. Gleichzeitig ist ein Ausnutzen von IDOR-Schwachstellen einfach, was diese so gefährlich macht. Der Industriestandard zur Ermittlung der Gefährlichkeit von Schwachstellen in Software ist das Common Vulnerability Scoring System, kurz CVSS. Dieser Score bewertet das Risiko je nach Voraussetzungen für den Angriff, Reichweite des Angriffs sowie verletzten Schutzzielen. Auf der CVSS-Skala sind IDOR-Schwachstellen meistens zwischen 6.0 und 8.2 Punkten von maximal 10.0 eingeordnet. Damit werden sie als Mittel- bis Hoch-Risiko-Schwachstellen klassifiziert.

In seltenen Fällen ist neben der Vertraulichkeit auch das Schutzziel der Integrität betroffen. Ein Nutzer könnte dann abstreiten bestimmte Aktionen durchgeführt, bzw. nicht durchgeführt zu haben. Ist das der Fall, beschränkt sich die Schwachstelle nicht nur auf Datenleaks und hat dann noch weitreichendere Folgen für alle Betroffenen. In unserem Beispiel wäre das der Fall, wenn der Angreifer mithilfe von IDOR Geld versenden kann. Der tatsächliche Nutzer kann dann nicht mehr nachweisen, nie Geld versendet zu haben. Hier wird sehr deutlich, wieso IDORs so gefährlich sind.

Ausblick

IDORs beschränken sich nicht nur rein auf Webapplikationen. In jeder Applikation, in der ein Nutzer direkt auf ein Objekt referenziert, um darauf zuzugreifen, können IDORs auftreten. In unserem Beispiel ist das Objekt, welches referenziert wird, zwar eine Website, das muss aber nicht immer so sein. Wenn ein Nutzer in einer Anwendung beispielsweise auf ein Dateisystem zugreifen kann, muss auch hier sichergestellt werden, dass dieser dazu berechtigt ist. Wird das nicht überprüft, kann der Nutzer eventuell Dateien lesen, welche nicht für ihn bestimmt sind. Auch das wäre eine Form von IDOR. Genauso kann dieses Problem auch bei Applikationen auf Mobilgeräten auftreten, etwa wenn Apps Daten von anderen Apps lesen können. Wenn das Betriebssystem des Handys nicht sicherstellt, dass es nur bei den Daten dieser einen App bleibt, ist auch das wiederum eine Form von IDOR. 

Fazit

Insecure Direct Object Reference-Schwachstellen sind eine Bedrohung für geschützte Daten in Webapplikationen. Diese entstehen durch unzureichende Zugriffskontrolle und können Folgen wie Datenleaks und die Verbreitung sensibler Informationen haben. Mithilfe des Einsatzes von Cookies kann eine IDOR-Schwachstelle behoben werden.

Bevor Sie eine Webapplikation veröffentlichen, sollten also diese und andere Schwachstellen beseitigt werden. Mit einer Sicherheitsüberprüfung, einem Secure Source Code Review und/oder einem Pentest lassen sich diese Schwachstellen identifizieren und beheben. Wir helfen Ihnen gerne dabei.

Seminarempfehlung