Fehlerhaftes Berechtigungsmanagement

2021 wurden Berechtigungsfehler zum ersten Mal in der Laufbahn vom OWASP Top 10 Projekt als das größte Risiko in Webanwendungen eingestuft. Wie wir noch feststellen werden, erfordert die Suche nach Autorisierungsfehlern eine penible und strukturierte Herangehensweise. So benötigen wir für den Test der Zugriffskontrollen ein grundlegendes Verständnis über die Funktionalität einer Anwendung, weshalb wir die folgenden Fragen klären sollten:

• Welche Benutzerrollen wurden implementiert?
• Welche Berechtigungen wurden den einzelnen Benutzerrollen zugewiesen und inwieweit unterscheiden sie sich voneinander?
• Ist das Zielsystem mehrmandenfähig?

Aus diesen Fragen können wir zwei wesentliche Prüfpunkte ableiten: die Überprüfung der horizontalen und vertikalen Benutzerautorisierung. Während die Überprüfung der horizontalen Rechteausweitung auf den Zugriff fremder Benutzerdaten abzielt, wird im Rahmen der vertikalen Rechteausweitung versucht, sich Privilegien anderer Benutzerrollen zu bedienen. Derartige Schwachstellen könnten beispielsweise durch eine Manipulation von IDs in HTTP-Endpunkten identifiziert werden. Ohne Kenntnis des Datenbestands einer Anwendung tappen wir jedoch bei der Analyse im Dunkeln. Dabei sollten wir uns in Erinnerung rufen, dass wir für die Durchführung eines Pentests nur begrenzt Zeit haben. Um den Kosten-Nutzen-Faktor zu erhöhen, sollten wir mindestens zwei Benutzerkonten pro Rolle beim Auftraggeber anfragen. Mit diesen Zugangsdaten können wir aus verschiedenen Sichtweisen durch eine Anwendung navigieren, alle HTTP-Requests mit einem Proxy abfangen und anschließend die Session-IDs oder Access-Tokens mit denen anderer Benutzerkonten austauschen. Wie aus der folgenden Grafik entnommen werden kann, bräuchten wir beispielsweise 8 Testaccounts, wenn in einer Anwendung drei Benutzerrollen implementiert wurden und zudem mehrmandenfähig ist:

Nehmen wir beispielsweise an, dass wir in einem Customer-Relationship-Management-System (CRM) prüfen wollen, ob ein Projektleiter sich die Admin-Rolle über die für ihn verborgene Benutzerverwaltung zuweisen kann. Hierzu müssten wir eine Sitzung mit den Testaccounts 'pentest-projektleiter-01' und 'pentest-admin-01' initialisieren und deren Session-Cookies zwischenspeichern:

pentest-projektleiter-01

Set-Cookie: JSESSIONID=E887430CAB542256EF52E56FF6204295; Path=/; HttpOnly

pentest-admin-01

Set-Cookie: JSESSIONID=50B6753AB49518F9121C05CF6C64280B; Path=/; HttpOnly

Anschließend würden wir als Benutzer 'pentest-admin-01' die Änderung der Benutzerrolle von 'pentest-projektleiter-01' über die Benutzeroberfläche des CRMs veranlassen und das Session-Cookie im abgefangenen HTTP-Request in der Burp Suite mit dem Session-Cookie von 'pentest-projektleiter-01' austauschen:

POST /user/31  HTTP/1.1
Host: crm.dubius-payment.com
Cookie: JSESSIONID=E887430CAB542256EF52E56FF6204295
Content-Type: application/json
Content-Length: 51
Connection: close

{
    "data":{
        "admin_flag":1
    }
}

Diese Prozedur müssten wir für alle Kombinationsmöglichkeiten innerhalb einer Berechtigungsstruktur durchspielen, um keinen Berechtigungsfehler zu übersehen. Dabei dürfen wir uns von eigenen Logikfehler nicht beirren lassen. Ein möglicher Fallstrick bei der Überprüfung des Berechtigungsmanagements sind beispielsweise Löschvorgänge. So können wir selbstverständlich nur Daten löschen, wenn diese in der Anwendung existieren. Bei Unachtsamkeit könnten wir aber die HTTP-Request-Methode 'DELETE' auf eine Ressource ausführen, die von uns bereits gelöscht worden ist, wodurch sich das Ergebnis unseres Autorisierungstests verfälschen würde.

Neben der Überprüfung der horizontalen und vertikalen Autorisierung müssen wir auch verifizieren, dass eine vorliegende Benutzerauthentifizierung nicht über direkte Seitenaufrufe umgangen werden kann. Im Detail bedeutet dies, dass wir alle abgefangenen HTTP-Requests aus Sicht der verschiedenen Benutzerrollen ohne Identifikationsmerkmale wie einer Session-ID oder einem Access-Token absetzen müssen.