Dieser Beitrag aus unserer Reihe zur OWASP Top 10, den zehn häufigsten Sicherheitslücken in Webapplikationen, beschäftigt sich mit Fehlern in der Zugriffskontrolle und der damit verbundenen horizontalen oder vertikalen Rechteausweitung.

Zugriffsrechte für authentifizierte Nutzer werden in Webapplikationen häufig nicht korrekt um- bzw. durchgesetzt. Dieser Umstand ermöglicht es schließlich Angreifern, auf Funktionen oder Daten zuzugreifen, für die sie eigentlich keine Zugriffsberechtigungen besitzen. Konkret kann dies Zugriffe auf Accounts anderer Nutzer und vertrauliche Daten oder aber auch die Manipulation von Nutzerdaten und Zugriffsrechten zur Folge haben.

Beispielszenarien

Zu den häufigsten Schwachstellen in den Zugriffskontrollmechanismen gehören:

  • Das Umgehen der Zugriffskontrollprüfungen durch die Änderung der URL, des internen Anwendungsstatus, des HTML-Quellcodes oder die Verwendung eines API-Angriffswerkzeugs. In diesem Zusammenhang steht auch der Zugriff auf die API durch eine fehlende Zugriffskontrolle für POST, PUT oder DELETE Anfragemethoden. Die folgende Abbildung versinnbildlicht diesen Vorgang:

  • Die Manipulation des Primärschlüssels eines Nutzerkontos, so dass der Account eines anderen Nutzers angezeigt bzw. bearbeitet werden kann.

Konkret vorstellbar wäre z. B. eine Anwendung, die nicht verifizierte Daten in einem SQL-Aufruf verarbeitet, welcher auf Kontoinformationen zugreift:

pstmt.setString(1, request.getParameter(„konto“));

ResultSet results = pstmt.executeQuery();

Ein Angreifer könnte nun im Browser den Parameter „konto“ in einen beliebigen Primärschlüssel ändern. Erfolgt durch die Anwendung keine Verifikation der Eingangsdaten, dann kann im Rahmen einer horizontalen Rechteausweitung auf ein beliebiges Nutzerkonto zugegriffen werden:

http://beispiel.de/app/kontoInfo?konto=andereskonto

  • Die Möglichkeit der vertikalen Rechteausweitung, indem ohne Anmeldung oder als unprivilegierter Benutzer administrativ gehandelt werden kann.

Beispielhaft erzwingt ein Angreifer den Aufruf einer dieser Ziel-URLs, welche eigentlich erst nach einer erfolgreichen Authentifizierung zugänglich sein sollten:

http://beispiel.de/app/getappInfo

http://beispiel.de/app/admin_getappInfo

Für den Zugriff auf den Admin-Bereich „admin_getappInfo“ sind zudem erhöhte Berechtigungen notwendig. Falls ein unangemeldeter Nutzer auf eine der URLs zugreifen kann, liegt bereits ein Sicherheitsproblem vor. Eine entsprechende vertikale Rechteausweitung existiert natürlich auch, wenn ein Nicht-Administrator auf den Admin-Bereich zugreifen kann.

  • Die Verwendung von Metadatenmanipulationen, um Berechtigungen auszuweiten. Zu nennen sind hier die Manipulation oder die erneute Nutzung eines JSON Web Tokens (JWT), Zugriffskontroll-Tokens, Cookies oder versteckten Feldes.
  • Fehlerhafte Konfigurationen von CORS (Cross-Origin Resource Sharing), die einen unbefugten API-Zugriff ermöglichen.
  • Administrative Funktionen werden für Standardbenutzer lediglich ausgeblendet, sind server- bzw. API-seitig allerdings weiterhin aufrufbar.

Gegenmaßnahmen

Eine wirksame Zugriffskontrolle kann nur garantiert werden, wenn sie im vertrauenswürdigen serverseitigen Anwendungscode verankert ist, so dass der Angreifer die Zugriffskontrollprüfung oder die zum Einsatz kommenden Metadaten nicht manipulieren kann. Von clientseitigen Zugriffskontrollen wird generell abgeraten. Zudem wird empfohlen, die folgenden Punkte zu beachten:

  • Standardmäßig sollten Anfragen auf nicht öffentliche Ressourcen verweigert werden.
  • In der gesamten Anwendung sollten Zugriffskontrollmechanismen einmalig, d.h. zentral, implementiert werden. Dies betrifft ebenfalls die Definitionen – und damit eben auch mögliche Fehlkonfigurationen – von CORS, welche zudem so restriktiv, wie möglich, gestaltet werden sollen. Der Einsatz von Wildcards „*“ sollte dabei gut überlegt sein.
  • Die Berechtigung für Datensätze müssen durch die Zugriffskontrollmechanismen anhand des Dateneigentümers kontrolliert werden. Nutzer dürfen nicht beliebige Datensätze erstellen, aktualisieren oder löschen können.
  • Durch Berechtigungskonzepte sollte vermieden werden, Nutzern widersprüchliche oder sich gegenseitig ausschließende Berechtigungen zu gewähren. Letzteres sind Berechtigungs-Sets, die einem Nutzer zwar gleichzeitig zugeordnet sein, aber nicht gleichzeitig vom Nutzer ausgeführt werden können.
  • Verzeichnisauflistungen sollten bei Webservern deaktiviert und in Web-Root-Verzeichnissen sollte auf Meta- sowie Backupdateien, wie z. B. „.git“ bei Git-Repositories, verzichtet werden.
  • Eine Protokollierung muss zumindest bei wiederholten Zugriffsfehlern geschehen und zuständige Administratoren sollten benachrichtigt werden.
  • Um den Schaden durch automatisierte Angriffswerkzeuge zu beschränken, sollten API-Zugriffe über Quotas respektive eine sukzessive Drosselung geregelt werden.
  • Der Server sollte nach einem Abmeldevorgang den zugehörigen JWT sowie andere Anmeldedaten (z. B. Session-Cookies) invalidieren. JWTs können dabei auf eine temporäre Block-Liste gesetzt werden, bis deren Lebensdauer abgelaufen ist.
  • Zugriffsrechte sind immer serverseitig zu überprüfen und nicht nur durch das Ausblenden einer Schaltfläche umzusetzen.
  • Die Zugangs- und Zugriffskontrolle sollte bereits während der Entwicklung eine fundamentale Rolle spielen und in funktionalen Unit- und Integrationstests einbezogen werden.

Zusammenfassung

Häufig treten Schwachstellen bei der Zugriffskontrolle in Webapplikationen auf, da eine automatisierte Erkennung bzw. korrekte Funktionstests in der Entwicklung fehlen. Angreifer können daraufhin fehlerhafte Zugangskontrollen umgehen und sich als ein anderer Nutzer (horizontale Rechteausweitung) oder sogar als Administrator (vertikale Rechteausweitung) ausgeben. Darüber hinaus können Angreifer bei Ausnutzen dieses Angriffsvektors privilegierte Funktionen verwenden und Datensätze erstellen, anfordern, aktualisieren oder löschen. Grundsätzlich eignen sich statische oder dynamische Tests nicht für die Erkennung von angemessenen Zugangskontrollen. Letzten Endes bleibt meistens nur das manuelle Testen, um nicht vorhandene oder ineffektive Zugriffskontrollmechanismen zu erkennen.