OWASP Top 10 – Broken Access Control

Wer sich mit IT Security befasst, kommt an den OWASP Top 10 nicht vorbei. Die Non-Profit-Organisation Open Web Application Security Project (OWASP) veröffentlicht in dieser zuletzt 2021 upgedateten Liste die 10 kritischsten Sicherheitsrisiken für Webanwendungen. Auf Platz 1 dieser Liste steht die Broken Access Control, die wir in diesem Beitrag in Theorie und Praxis behandeln. Nach einer Klärung der Basics zeigen wir dir 3 Broken Access Control Attacks im OWASP Juiceshop. Zum Schluss erklären wir, wie du deine Webanwendung gegen solche Attacken schützen kannst.

Inhaltsverzeichnis

Grundlagen: OWASP Top 10 und Broken Access Control

Was ist OWASP?

Das Open Web Application Security Project, kurz OWASP, ist eine internationale Non-Profit-Organisation, die sich für die Sicherheit von Webanwendungen einsetzt. Die Arbeit der OWASP umfasst mehrere freie Projekte, welche sich von der Entwicklung über das Testing bis hin zum sicheren Betrieb von Webanwendungen befassen. Ihr wohl bekanntestes Projekt: Die OWASP Top 10.

Die OWASP Top 10

OWASP veröffentlicht in regelmäßigen Abständen eine aktualisierte Liste mit den zehn kritischsten Sicherheitsrisiken für Webanwendungen. Die letzte Aktualisierung erfolgte im Jahr 2021.

OWASP selbst bezeichnet die Top 10 als „Sensibilisierungsdokument“ und nur als das Minimum in Bezug auf die Sicherheit, welche mit Webanwendungen einhergehen sollte. Für einen ersten Einstieg in das Thema Sicherheit in Webanwendung sind die TOP 10 aber genau richtig. Wer sich jedoch tiefer mit dem Thema beschäftigt, der sollte je nach Anwendungsfall auf die Projekte OWASP Web Security Testing Guide (WSTG) oder OWASP Application Security Verification Standard (ASVS) zurückgreifen, da diese die Themen tiefer behandeln.

An der Spitze der OWASP Top 10 steht die Broken Access Control, mit der wir uns in diesem Beitrag theoretisch und praktisch befassen.

Wie sicher ist deine Web Application?
Bist du gegen alle OWASP Top 10 Sicherheitsrisiken gewappnet?
Zum Web Application Penetration Test

A01:2021 - Broken Access Control

Bevor wir uns mit dem Thema Broken Access Control (dt. fehlerhafte Zugriffskontrolle) beschäftigen, müssen wir zuerst einmal klären, was Access Control (dt. Zugriffskontrolle) mit Blick auf Webanwendungen bedeutet: 

Eine Access Control beschreibt die Rechte und Einschränkungen eines Objektes auf eine Ressource oder eine Aktion.

Zum Beispiel sollte ein Benutzer mit seinem Onlinebanking Account nur auf seine eigenen Konten zugreifen und dort entsprechend auch Buchungen vornehmen dürfen. Der Zugriff auf das Konto eines anderen Benutzers sollte aber nicht gestattet sein.

Wir unterteilen die Access Control in folgende Kategorien:

  • Die horizontale Access Control: Horizontale Zugriffskontrollen sind Mechanismen, die den Zugriff von Benutzern auf die Ressourcen beschränken, für welche die Benutzer auch autorisiert sind. Hierunter fällt das eben beschriebene Szenario des Onlinebankings.
  • Die vertikale Access Control: Vertikale Zugriffskontrollen werden verwendet, um den Zugriff auf wichtige Funktionen zu begrenzen, welche nicht für andere Benutzertypen zur Verfügung stehen sollen. Das bedeutet, dass verschiedene Arten von Benutzern Zugriff auf verschiedene Anwendungsfunktionen haben. Zum Beispiel kann ein Administrator das Konto eines beliebigen Benutzers ändern oder löschen, während ein normaler Benutzer keinen Zugriff auf diese Aktionen hat.
  • Die kontextabhängige Access Control: Kontextabhängige Zugriffskontrollen schränken den Zugriff auf Funktionen und Ressourcen anhand eines Status oder der Interaktion des Benutzers mit der Anwendung ein. Zum Beispiel verhindert die kontextabhängige Zugriffskontrolle, dass ein Benutzer Aktionen in der falschen Reihenfolge ausführt und den Inhalt seines Einkaufswagens auf einer Shopping-Webseite ändert, nachdem er die Ware bereits gekauft hat.

Im Hinblick auf die Access Control müssen wir aber auch die Authentifizierung und das Sessionmanagement beachten, da diese den Ausgangspunkt für die Access Control darstellen.

  1. Durch die Authentifizierung meldet sich der Benutzer an, um autorisiert zu werden.
  2. Durch das Sessionmanagement wird sichergestellt, dass nachfolgende HTTP-Anforderungen auch von demselben Benutzer stammen, da das Internetprotokoll HTTP zustandslos arbeitet. Das heißt, sobald eine Anforderung eines Clients vom Webserver bearbeitet ist, wird die Verbindung wieder getrennt. Da ein Benutzer aber nicht auf jeder neu aufgerufenen Seite seine Anmeldeinformationen erneut eingeben möchte, muss die Information in irgendeiner Art und Weise gespeichert, transportiert und verifiziert werden.

Da nun geklärt ist, was eine Access Control ist, wird auch verständlich, was mit einer Broken Access Control oder einer fehlerhaften Zugriffskontrolle gemeint ist:

Eine Broken Access Control liegt vor, wenn ein Benutzer die vertikalen, horizontalen oder kontextabhängigen Zugriffskontrollen umgehen kann. Vereinfacht ausgedrückt: Benutzer erhalten Zugriff auf sensible Daten oder dürfen Aufgaben ausführen, für die sie nicht berechtigt sein sollten.

Praxistest OWASP Top 10: Broken Access Control Attacks

Was hat der OWASP Juice Shop mit den OWASP Top 10 zu tun?

Der OWASP Juice Shop ist eine Webanwendung mit sehr vielen Sicherheitslücken. Die Anwendung soll jedem ermöglichen, die OWASP Top 10 einmal selbst auszunutzen, ohne sich strafbar zu machen.

Für ein besseres Verständnis schauen wir uns nachfolgend drei Broken Access Control Angriffe anhand des OWASP Juice Shop an.

  1. Attack: Post some feedback in another user’s name. (dt. Angriff: Posten Sie Feedback im Namen eines anderen Benutzers.)
  2. Attack: View another user’s shopping basket. (dt. Angriff: Lassen Sie sich den Warenkorb eines anderen Benutzers anzeigen.)
  3. Attack: Put an additional product into another user’s shopping basket. (dt. Angriff: Legen Sie ein zusätzliches Produkt in den Warenkorb eines anderen Benutzers.)

Der OWASP Juice Shop kann auf Windows, MacOS oder Linux installiert oder als Container genutzt werden. Die Dokumentation des Juice Shops ist zwar auf Englisch, aber dennoch sehr gut beschrieben:

Installation OWASP Juice Shop

Achtung: Beim OWASP Juice Shop handelt es sich um eine Anwendung mit sehr vielen und leicht ausnutzbaren Sicherheitslücken. Daher solltest du diese auf einem Testgerät installieren, das nur für dich selbst zugänglich ist.

In unserem Fall haben wir uns für den Docker Container entschieden, da Docker selbst leicht zu installieren und der OWASP Juice Shop Container schnell heruntergeladen und gestartet ist.

Beim Starten des Docker Containers muss beachtetet werden, dass die Variable

				
					NODE_ENV=unsafe
				
			

mitübergeben wird, damit alle Broken Access Control Angriffe (Challenges) auch ausprobiert werden können. Dies kann über die Docker Desktop Oberfläche geschehen:

Docker Desktop Oberfläche

oder man starten den Container über die Shell:

				
					docker run --name juice-shop -e "NODE_ENV=unsafe" -p 3000:3000 bkimminich/juice-shop
				
			

Zum Ausnutzen der Sicherheitslücken kann ein beliebiger Browser genutzt werden (Schwierigkeitsgrad: Hoch). Wir empfehlen hier aber die Verwendung eines Proxy Servers. Mehr hierzu findet ihr in unserem Proxy Grundlagenartikel.

Im weiteren Verlauf des Artikels verwenden wir die Burp Suite Community Edition.

3 Broken Access Control Attacks im OWASP Juice Shop

Hast du den OWASP Juice Shop gestartet?

Die Burp Suite Community Edition geöffnet?

Hast du beide Fragen mit Ja beantwortet, können wir loslegen.

In der Burp Suite Community Edition wählen wir, wenn nicht schon vorausgewählt, den Proxy Tab aus.

Burp Suite Community Edition “Proxy” Tab

Danach öffnen wir über Open Browser den Browser…

Burp Suite Open Browser

…und gehen auf die Webseite:

				
					http://"Docker-IP":3000
				
			

Da wir Docker lokal installiert haben, erreichen wir unseren Juice Shop unter der Adresse http://127.0.0.1:3000.

Owasp Juice Shop

Wenn alles richtig eingerichtet ist, sehen wir jetzt die Startseite des OWASP Juice Shop und können mit der ersten Challenge beginnen.

Anmerkung: Die nachfolgenden Angriffe inkl. der Lösungen sind auch in der Dokumentation des OWASP Juice Shops zu finden:

Attack 1: Post some feedback in another user's name.

Möglichkeit 1

Im ersten Schritt klicken wir oben links auf das Burger-Menü und wählen About Us aus.

OWASP Top 10
OWASP Juice Shop

Auf dieser Seite stehen im Slider die vorhandenen und schon abgegebenen Feedbacks.

OWASP Juice Shop

Nun gehen wir über das Burger-Menü auf die Seite Customer Feedback.

OWASP Juice Shop

Hier können wir zum Test einmal selbst ein Feedback abgeben, welches wir auf der About Us Seite danach ansehen können.

OWASP Juice Shop
OWASP Top 10

Um nun das Feld Author bzw. die UserID zu manipulieren, fangen wir den POST Request an den Webserver ab (Interception) und ändern diesen.

Dafür schauen wir uns in Burp Suite unter dem Reiter HTTP history zuerst den getätigten POST Request an.

Burp Suite unter dem Reiter „HTTP history“

Und danach die Response des Webservers.

Dabei fällt auf, dass dort ein UserID Feld mit dem Wert null vorhanden ist.

Response des Webservers

Dies gibt uns den Hinweis, dass der Server eine UserID bei der Abgabe eines Feedbacks benötigt. Dieses Feld wiederum können wir versuchen, in den darauffolgenden POST Request zu manipulieren. Dafür starten wir in Burp Suite im Reiter Intercept mit einem Klick auf Intercept is off das Abfangen der Webanfragen.

Burp Suite im Reiter „Intercept“

Steht der Button auf Intercept is on, geben wir erneut ein Feedback ab.

Steht der Button auf „Intercept is on“, geben wir erneut ein Feedback ab.
Steht der Button auf „Intercept is on“, geben wir erneut ein Feedback ab.

Wir merken, dass wir dieses Mal kein Pop-up-Fenster erhalten haben, welches uns die Abgabe des Feedbacks bestätigt. Das liegt daran, dass wir die Webanfragen durch unseren Proxy gestoppt haben, um diese zu manipulieren.

Dafür gehen wir zurück in die Burp Suite und klicken im Reiter Intercept so lange auf den Button Forward, bis wir den POST Request unseres Feedbacks sehen.

Burp Suite Reiter „Intercept“

Diesen manipulieren wir nun, indem wir den Parameter UserID mit einem Wert hinzufügen und auf den Button Forward klicken. Danach können wir die Interception wieder ausschalten und im Reiter HTTP history unseren manipulierten POST Request ansehen.

Parameter „UserID“ Button „Forward“

Hier sehen wir, dass der Server unseren POST mit der geänderten UserID erfolgreich angenommen hat. Damit haben wir das Feedback nicht mehr mit der UserID null (anonymous) abgegeben, sondern als Benutzer mit der UserID 2. Ein erfolgreicher Broken Access Control.

Ein erfolgreicher Broken Access Control.
Möglichkeit 2

Eine weitere Möglichkeit, diese Challenge zu lösen, ist das Anzeigen des versteckten UserID Feldes auf der Webseite Customer Feedback.

„UserID“ Feldes auf der Webseite „Customer Feedback“.

Um das versteckte Feld anzuzeigen, öffnen wir über Rechtsklick – Untersuchen die Entwicklertools.

„Rechtsklick - Untersuchen“ die „Entwicklertools“.
OWASP Juice Shop

In dem Reiter Elements suchen wir mit der Standard Tastaturkombination STRG+F nach dem Wort hidden (dt. versteckt).

In dem Reiter „Elements“ suchen wir mit der Standard Tastaturkombination STRG+F nach dem Wort „hidden“ (versteckt).

Wir suchen die Zeile:

				
					   <input _ngcontent-reo-c122="" hidden="" type="text" id="userId" class="ng-untouched ng-pristine ng-valid">
				
			

Wenn wir die Zeile gefunden haben, sehen wir das Feld id=”userId” vom type=“text“. Dieses ist versteckt, also hidden.

Wir entfernen das „hidden“

Wir entfernen das hidden und schon sehen wir auf der Webseite das UserID Feld, in welches wir jede ID eintragen können, die wir wollen: Eine Broken Access Control.

Broken Access Control
Broken Access Control

Attack 2: View another user's shopping basket.

Möglichkeit 1

Für diesen Angriff müssen wir uns als Benutzer anmelden. Hierzu klicken wir oben rechts auf Account und wählen Login aus.

OWASP Juice Shop
OWASP Juice Shop Login

Danach melden wir uns als Benutzer jim an.

E-Mail-Adresse: jim@juice-sh.op

Passwort: (egal, darf nur nicht leer sein)

Die Besonderheit bei der Anmeldung ist, dass wir das Passwort von jim nicht kennen. Deshalb müssen wir die Anmeldung über eine SQL Injection durchführen. Dieses geschieht durch den Zusatz ‚‐‐ am Ende der E-Mail-Adresse.

Erklärung: Das Hochkomma beendet den String des E-Mail-Feldes in der SQL-Abfrage und die beiden Bindestriche ‐‐ geben an, dass alles, was nach den beiden Bindestrichen folgt, ein Kommentar ist. Das heißt, das Passwort wird in der Abfrage auskommentiert.

Ein Blogbeitrag zum Thema SQL Injection folgt.

OWASP Juice Shop Login
OWASP Juice Shop Warenkorb „Your Basket“

Nach erfolgreicher Anmeldung rufen wir unseren Warenkorb Your Basket auf.

OWASP Juice Shop Warenkorb „Your Basket“

Danach suchen wir in unserer HTTP history in Burp Suite nach den Warenkorb Aufruf. In dem Request fällt auf, dass in der URL die UserID (im Fall von jim = UserID 2) mit angeben ist.

“HTTP history” in Burp Suite

Lasst uns diese doch mal verändern.

Dazu starten wir die Interception in Burp Suite und rufen den Warenkorb Your Basket erneut auf.

OWASP Juice Shop Warenkorb „Your Basket“

Im dem GET Request vom Warenkorb Aufruf können wir, wie im ersten Angriff, die Paramenter oder Felder manipulieren.

OWASP Juice Shop Warenkorb „Your Basket“

Wir verändern in der URL die 2 zu einer 1 (die UserID des Admins) und klicken auf Forward. Danach stoppen wir die Interception und schauen uns im Browser das Ergebnis an.

OWASP Juice Shop Warenkorb „Your Basket“

Unser Warenkorb ist nun ein anderer. Und wieder liegt eine Broken Access Control vor.

Broken Access Control

Das Ergebnis können wir uns aber auch noch einmal in unserer HTTP history anschauen. Dort sehen wir auch die Antwort auf unseren manipulierten GET Request.

HTTP history
Möglichkeit 2

Wie auch im ersten Angriff gibt es in dieser Challenge eine zweite Lösungsmöglichkeit.

Hierzu öffnen wir wieder die Entwicklertools und schauen uns dieses Mal im Reiter Application unseren Session Storage an.

Entwicklertools Reiter Application Session Storage

Dort finden wir den Parameter bid, der möglicherweise für BasketID steht, mit dem Wert 2. Da unsere Benutzer ID 2 ist, ist das naheliegendste, dass der Wert 2 in bid auch in Verbindung mit der UserID steht.

Wir verändern den Wert 2 zu 1 und laden die Webseite des Warenkorbes neu.

Verändern einmal den Wert 2 zu 1

Und auch dieses Mal sehen wir nicht mehr jim’s Warenkorb, sondern den des Admins. Das heißt, auch auf diesem Weg liegt eine Broken Access Control vor.

Broken Access Control

Attack 3: Put an additional product into another user's shopping basket.

Unsere letzte Challenge.

Das Vorgehen am Anfang ist aber dasselbe. Wir führen die Aktion, welche wir testen oder manipulieren wollen, einmal aus.

Fruit Press

Das heißt, wir legen ein Produkt in unseren Warenkorb. Wir haben uns für die Fruit Press entschieden.

Fruit Press

Danach schauen wir uns den Vorgang in der HTTP history an. In dem POST Request stellen wir fest, dass eine BasketID übergeben wird.

POST Request „BasketID wird übergeben

Diese versuchen wir wieder zu manipulieren. Wir verändern also die Parameter und Felder, während wir den Webaufruf mit dem Vorgang der Interception stoppen, manipulieren und wieder weiterleiten. Dabei fällt uns auf, dass das Ändern der BasketID uns hier nicht zum Ziel führt.

Also müssen wir unseren POST Request in diesem Fall anders manipulieren. Anstelle einer Parameterveränderung fügen wir dieses Mal einen Parameter hinzu (HPP = HTTP parameter pollution).

Wichtig: In diesem Juice Shop Szenario ist zu beachten, dass der hinzugefügte Artikel nicht schon im Warenkorb des angemeldeten Benutzers vorhanden ist. Bei dem hier gezeigten Angriff haben wir die Fruit Press vor der Interception aus jim’s Warenkorb gelöscht.

„Fruit Press“ vor der Interception aus jim’s Warenkorb gelöscht
„Fruit Press“ vor der Interception aus jim’s Warenkorb gelöscht

Nachdem wir den POST an den Webserver übergeben haben, können wir in der Response des Servers im Reiter HTTP history eine erfolgreiche Broken Access Control sehen.

Broken Access Control

Da wir inzwischen wissen, wie wir uns den Warenkorb des Admins anzeigen lassen können, können wir unseren erfolgreichen Angriff auch im Browser kontrollieren: Das Produkt Fruit Press ist dem Warenkorb des Admins hinzugefügt.

Das Produkt „Fruit Press“ ist dem Warenkorb des Admins hinzugefügt.

OWASP Top 10 Solution: So schützt du deine Webanwendung vor Broken Access Control Attacks

Die eine passende Lösung für eine Broken Access Control gibt es leider nicht, da jede Webanwendung bzw. jede Access Control sich in ihrer Umsetzung unterscheidet. Jedoch gibt es einige Punkte, die man beachten kann:

  1. Die Implementierung von Zugriffskontrollen in der gesamten Webanwendung
  2. Ein ausgearbeitetes und dokumentiertes Rollen-, Rechte- und Auditierungskonzept
  3. Eine saubere Protokollierung von Fehlern
  4. Session Cookies sollten nach der Abmeldung auf dem Server ungültig gemacht werden
  5. Zustandslose JWT-Token sollten eher kurzlebig sein
  6. Das Befolgen der OAuth-Standards
  7. Eine Sensibilisierung der Entwickler
  8. Die Implementierung und Konfiguration einer Web Application Firewall (WAF)

Empfehlung: Da Webanwendungen unterschiedlich sind und sich im Laufe der Zeit verändern, empfehlen wir eine regelmäßige Durchführung von Audits und Web Application Penetration Tests, um fehlerhafte Broken Access Control Schwachstellen aufzuzeigen.

Brauchst du Unterstützung beim Hardening deiner Web App?
Wir finden für dich alle Sicherheitslücken und führen dich durch deren Schließung.
Zum Web Application Penetration Test
Follow for more!
Newsletter Form

Become a Cyber Security Insider

Sichere dir frühen Zugang und exklusive Inhalte!


Mit deiner Anmeldung erklärst du dich damit einverstanden, gelegentlich Marketing-E-Mails von uns zu erhalten.
Bitte akzeptiere die Cookies unten auf dieser Seite, um das Formular abschicken zu können!
ANDERE BEITRÄGE

Inhaltsverzeichnis

PSN_KU_Cover
NewsLetter Form Pop Up New

Become a Cyber Security Insider

Abonniere unsere Knowledge Base und erhalte:

Frühen Zugriff auf neue Blogbeiträge
Exklusive Inhalte
Regelmäßige Updates zu Branchentrends und Best Practices


Mit deiner Anmeldung erklärst du dich damit einverstanden, gelegentlich Marketing-E-Mails von uns zu erhalten.
Bitte akzeptiere die Cookies unten auf dieser Seite, um das Formular abschicken zu können!