Broken Access Control taucht immer wieder in den Schwachstellenkategorien der OWASP Top 10 Web Application Security Risks auf und stellt derzeit die größte Herausforderung für die Sicherheit von Webanwendungen dar. Ein übermäßiges Vertrauen in automatisierte Lösungen zur Bewältigung dieser Herausforderung vermittelt ein trügerisches Bild von Sicherheit und könnte schwerwiegende Konsequenzen für die Verantwortlichen von Websites haben.

Schwachstellen in der Zugriffskontrolle ermöglichen Benutzern den Zugriff auf sensible Daten und geben ihnen die Möglichkeit, Aktionen durchzuführen, die über die für sie vorgesehenen Berechtigungen hinausgehen. Die Folgen solcher Schwachstellen können zur Offenlegung, Änderung und sogar Zerstörung von Daten führen.

In diesem Beitrag gehen wir darauf ein, warum Sicherheitslücken in der Zugriffskontrolle oft auch nach Vulnerability-Scans und -Assessments noch vorhanden sind und wie wichtig manuelle Penetrationstests für eine effektive Identifizierung und Behebung sind.

Was bedeutet Zugriffskontrolle (Access Control)?

Die Zugriffskontrolle kann man sich als eine Berechtigungsprüfung vorstellen, die sicherstellt, dass der Zugriff auf Ressourcen und die Möglichkeit, Aktionen auszuführen, bestimmten Benutzern (z. B. Administratoren) gewährt wird und anderen (z. B. normalen Benutzern) nicht. Diese Prüfungen werden meist nach dem Authentifizierungsprozess durchgeführt, bei dem die behauptete Identität eines Benutzers überprüft wird.

Bei der Sicherheit von Webanwendungen ist die Zugriffskontrolle eng mit dem Inhalt, der beabsichtigten Nutzung der Funktionen und den verschiedenen Rollen der Benutzer verbunden. So kann beispielsweise verhindert werden, dass ein Benutzer mit geringen Rechten administrative Funktionen ausführt, dass ein Benutzer auf die Ressourcen eines anderen Benutzers zugreift oder dass der Zugriff auf Ressourcen oder Funktionen auf der Grundlage von kontextabhängigen Faktoren gewährt oder verweigert wird.

Bei großen und komplexen Anwendungen, die zahlreiche Benutzerrollen und Funktionen enthalten, kann die korrekte Implementierung von Zugriffskontrollen schnell zu einer Herausforderung werden.

Was versteht man unter „Broken Access Control“?

Eine fehlerhafte Zugriffskontrolle (Broken Access Control) ist genau das, wonach es klingt: eine Zugriffskontrolle, die nicht wie vorgesehen funktioniert. Dies wäre im Wesentlichen das Gegenteil von dem, was wir oben erwähnt haben, mit einigen detaillierten Beispielen, die folgen werden.

Insecure direct object reference (IDOR)

Nehmen wir eine Anwendung, die es normalen Benutzern ermöglicht, ihre Kontoinformationen einzusehen und zu bearbeiten. Jedem Konto wird eine Benutzer-ID zugewiesen. Wenn eine Editieranfrage gesendet wird, bestimmt die Anwendung anhand der in der Anfrage enthaltenen ID, welches Konto aktualisiert werden soll. In diesem Szenario könnte ein Angreifer eine ausgehende Anfrage zur Aktualisierung seines Kontos manipulieren, indem er die Benutzer-ID in die eines Opfers ändert.

Ohne eine Zugriffskontrolle würde das Konto des Opfers die Bearbeitung erhalten – eine IDOR-Schwachstelle mit direkten Auswirkungen auf die Integrität der Daten. Von diesem Punkt aus kann die Situation schnell eskalieren. Angenommen, der Angreifer ändert die E-Mail-Adresse des Opfers und fordert anschließend ein neues Kennwort an. Dies würde es ihm ermöglichen, ein neues Kennwort festzulegen und schließlich das Konto des Opfers zu übernehmen.

Nachdem wir uns nun Zugriff auf das Konto eines anderen Benutzers verschafft haben, sollten wir noch zwei weitere Begriffe klären, die häufig im Zusammenhang mit gebrochener Zugriffskontrolle auftauchen: horizontale Privilegieneskalation und vertikale Privilegieneskalation.

Horizontale Eskalation der Zugriffsrechte

Bei der horizontalen Eskalation geht es darum, sich mit ähnlichen Berechtigungen Zugang zu den Ressourcen eines anderen Kontos zu verschaffen. Wenn in dem Beispiel aus dem vorigen Abschnitt das Opferkonto über ähnliche Berechtigungen wie der angreifende Benutzer (d. h. ein normaler Benutzer) verfügt, würde man auch von einer horizontalen Privilegienerweiterung sprechen. Kurz gesagt, abgesehen vom Zugriff auf die Ressourcen eines anderen Kontos erhält der Angreifer keine zusätzlichen Berechtigungen.

Vertikale Eskalation der Zugriffsrechte

Bei der vertikalen Eskalation erhält der Angreifer Zugriff auf die Ressourcen eines anderen Kontos mit mehr Berechtigungen. Wenn in dem Beispiel aus dem vorigen Abschnitt das Opferkonto über höhere Berechtigungen verfügt (z. B. Moderator oder Administrator), wird dies als vertikale Privilegienerweiterung bezeichnet. Der Angreifer kann die zusätzlichen Berechtigungen missbrauchen, um weitere Angriffe gegen die Anwendung durchzuführen.

Path/Directory Traversal (Forceful Browsing)

Stellen Sie sich eine Webanwendung vor, die es Benutzern ermöglicht, ihre Rechnungen mit Hilfe einer integrierten Vorschaufunktion einzusehen. Die Rechnungen sind auf demselben Server gespeichert, auf dem auch die Anwendung gehostet wird, und zwar unter dem folgenden absoluten Pfad:

/var/www/html/vulnerable-application/invoices/

Wenn ein Benutzer auf eine der Rechnungen klickt, die unter seinem Profil angezeigt werden, wird die folgende Anfrage gesendet:

Der Previewer funktioniert, indem er den Wert des Parameters „file“ an den angegebenen absoluten Pfad anhängt. Er ruft dann den Inhalt dieser Datei ab und gibt ihn an den anfragenden Benutzer zurück.

/var/www/html/anfällige-anwendung/rechnungen/invoice-2024-12-24.pdf

Wie im IDOR-Szenario könnte ein Angreifer jedoch auch hier die ausgehende Anfrage abfangen und ihren „file“-Parameter in eine Datei ändern, die nicht abgerufen werden soll.

Ohne eine Zugriffskontrolle würde der Previewer nun versuchen, eine Datei abzurufen:

/var/www/html/vulnerable-application/invoices/../../../../../etc/hosts

Die Punkt-Punkt-Schrägstrich-Sequenz (../) geht im Pfad ein Verzeichnis zurück (geht zum übergeordneten Verzeichnis). Wir haben fünf dieser Sequenzen, was bedeutet, dass wir beim Wurzelpfad des Dateisystems (/) landen würden. Von diesem Punkt aus gelangen wir in das Verzeichnis etc, von wo aus wir die Datei hosts anfordern.

Die hosts-Datei, eine Standarddatei, die Hostnamen auf IP-Adressen abbildet, ist wahrscheinlich nicht die erste Wahl eines Angreifers. Wir verwenden sie hier nur, um zu zeigen, dass es möglich ist, Dateien außerhalb des Verzeichnisses der Anwendung abzurufen, auch bekannt als lokale Dateieinbindung. Ein Angreifer würde stattdessen versuchen, sensible Dateien sowohl innerhalb als auch außerhalb des Verzeichnisses der Anwendung abzurufen.

Sie können nicht eskalieren? Deeskalieren Sie!

Als letztes Beispiel möchten wir uns ein reales Beispiel aus einer kürzlich durchgeführten Analyse bei einem Kunden ansehen. Die Anwendung verfügte über mehrere Benutzerrollen, die scheinbar alle gut eingerichtet und ordnungsgemäß getrennt waren. Alle Versuche, die Berechtigungen eines regulären Benutzers zu erhöhen, Zugriff auf unbeabsichtigte Ressourcen zu erhalten und zugriffsberechtigte Aktionen durchzuführen, wurden dank zahlreicher Zugriffskontrollen verhindert.

Nach einer gründlichen Zuordnung der verschiedenen Benutzerrollen stellten wir jedoch eine Diskrepanz fest. So konnten bestimmte Rollen zwar die Konten anderer Benutzer bearbeiten und löschen, aber nur für Konten mit geringeren Berechtigungen als die eigenen. Benutzer mit diesen Berechtigungen konnten diese Aktionen auch nicht für ihr eigenes Konto durchführen. Was übersehen wurde, war die Möglichkeit, hochprivilegierten Benutzern eine weniger privilegierte Rolle zuzuweisen, wodurch alle Privilegien entzogen und ihre Konten herabgestuft wurden. Diese herabgestuften Konten würden nun die Bedingung erfüllen, von dem technisch gesehen weniger privilegierten Konto bearbeitet und gelöscht zu werden.

Da die Herausforderung, Zugriffskontrollen korrekt zu implementieren, mit der Komplexität der Anwendung zunimmt, gilt das Gleiche für die Identifizierung von Problemen bei der Zugriffskontrolle. Für die Identifizierung dieser Kontrollen sind manuelle Sicherheitsanalysen der beste Ansatz, da sie ein tieferes Verständnis des Kontexts und der beabsichtigten Nutzung der Anwendung voraussetzen.

Vulnerability Scans stoßen an ihre Grenzen

Vulnerability Scanner sind eine beliebte Lösung zur Identifizierung von Schwachstellen in Anwendungen. Wenn man sich jedoch allein auf sie verlässt, entsteht ein unberechtigtes Gefühl der Sicherheit für die Betreiber dieser Anwendungen. Zwar können diese Scanner kontinuierlich und schnell erste Ergebnisse liefern, aber sie sind nur begrenzt in der Lage, neue Angriffsvektoren oder Schwachstellen zu erkennen, die Intuition und logisches Denken erfordern.

Um dieses Argument zu untermauern, vergleichen wir die Schwachstellen in der Zugriffskontrolle mit einer anderen verbreiteten Schwachstelle mit ähnlicher Komplexität und Anforderung an das menschliche Gespür: Schwachstellen in der Geschäftslogik (Business Logic).

Schwachstellen in der Geschäftslogik treten auf, wenn das Design, die Implementierung oder die internen Prozesse einer Anwendung von der erwarteten Nutzung abweichen. Einige eindeutige und häufige Beispiele sind die Bestellung einer negativen Menge eines Produkts oder das mehrfache Einlösen desselben Rabattcodes.

Selbst bei diesen einfachen Beispielen werden die Grenzen eines Schwachstellenscanners deutlich. Ein Scanner wäre nicht in der Lage, das beabsichtigte Verhalten der Anwendung zu erkennen. Aus seiner Sicht ist eine negative Zahl immer noch eine Zahl, und die wiederholte Verwendung einer bestimmten Funktion ist nicht unbedingt schlecht. Im Gegensatz zu anderen Schwachstellen wie Cross-Site-Scripting (XSS) und SQL-Injection kann ein Scanner hier nicht einfach eine Eingabe machen und nach einem vordefinierten Muster in der Antwort der Anwendung suchen, um festzustellen, ob etwas angreifbar ist.

Von einem offensiven Standpunkt aus betrachtet, erfordert das Aufspüren von Schwachstellen in der Kategorie der fehlenden Zugriffskontrolle oder der Geschäftslogik die gleiche Denkweise und ein kontextspezifisches Verständnis der Anwendung. In vielen Fällen gibt es auch eine Reihe von Überschneidungen. Bei der Bewertung einer Datei-Upload-Funktionalität wäre ein Testfall beispielsweise das Hochladen eines unerwarteten Dateityps, z. B. einer SVG-Datei, die eine JavaScript-Nutzlast enthält, obwohl nur Bilddateien erlaubt sind. Während SVG die allgemeinen Bildkriterien erfüllt, ist das darin enthaltene JavaScript nicht dafür gedacht, vom Browser des Opfers geparst zu werden. Wenn dies der Fall ist, handelt es sich dann um eine Schwachstelle in der Geschäftslogik oder um eine Umgehung der Zugriffskontrollen?

Nehmen wir nun an, dass eine Dateiupload-Funktionalität alle unbeabsichtigten Dateien ordnungsgemäß verhindert. Ein geeigneter Testfall wäre hier das Hochladen einer erlaubten Datei an einen unbeabsichtigten Ort, z. B. ein Verzeichnis, für das der hochladende Benutzer keine Schreibrechte hat. Würde dieses Szenario auf die Umgehung von Zugriffskontrollen oder auf einen Fehler in der Geschäftslogik der Anwendung hindeuten? Beides ist denkbar.

In diesen Fällen ist ein Verständnis des beabsichtigten Zwecks der Datei-Upload-Funktionalität unerlässlich, um festzustellen, ob wir gegen Geschäftsregeln oder Zugriffskontrollen verstoßen.

In einem realen Szenario käme noch zusätzliche Komplexität in Form von Rechten, Rollen, externen Integrationen, Bibliotheken von Drittanbietern, Abhängigkeiten und so weiter hinzu.

Diese kontextspezifische Komplexität, bei der es darum geht, welcher Benutzer Zugriff auf welches Objekt haben sollte, welche Daten kurz vor der Offenlegung stehen, wann Race Conditions ausgenutzt werden können, wo Social-Engineering-Möglichkeiten wahrscheinlich sind usw., wird für einen Schwachstellen-Scanner kaum zu ermitteln sein.

Mit Pentests identifizieren Sie Sicherheitsrisiken bei der Zugriffskontrolle

Um Schwachstellen in der Zugriffskontrolle und andere logische Fehler aufzuspüren und zu entschärfen, müssen die Betreiber von Anwendungen automatisierte Scan-Lösungen durch manuelle Pentests und menschliches Urteilsvermögen ergänzen. Outpost24 bietet Pentesting-as-a-Service (PTaaS) an, das den Betreibern von Webanwendungen hilft, ein höheres Maß an Sicherheit und Risikoerkennung zu erreichen.

Die PTaaS-Lösung von Outpost24 bietet umfangreiche, benutzerdefinierte und fortlaufende manuelle Tests mit der Option, automatische Scans für eine kontinuierliche Überwachung zu nutzen. Im Gegensatz zu herkömmlichen Pentests werden Ihnen die Befunde in Echtzeit über ein spezielles Portal zur Verfügung gestellt, über das Sie auch für Rückfragen direkt mit unseren Sicherheitsexperten verbunden sind. Da alle Erkenntnisse von erfahrenen Pentestern überprüft werden, besteht bei diesem Service keine Gefahr von Falschmeldungen.