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.
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.
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.
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:
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.
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.
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.
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:
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.
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.
Danach öffnen wir über Open Browser den 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.
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:
Im ersten Schritt klicken wir oben links auf das Burger-Menü und wählen About Us aus.
Auf dieser Seite stehen im Slider die vorhandenen und schon abgegebenen Feedbacks.
Nun gehen wir über das Burger-Menü auf die Seite Customer Feedback.
Hier können wir zum Test einmal selbst ein Feedback abgeben, welches wir auf der About Us Seite danach ansehen können.
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.
Und danach die Response des Webservers.
Dabei fällt auf, dass dort ein UserID Feld mit dem Wert null vorhanden ist.
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.
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.
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.
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.
Eine weitere Möglichkeit, diese Challenge zu lösen, ist das Anzeigen des versteckten UserID Feldes auf der Webseite Customer Feedback.
Um das versteckte Feld anzuzeigen, öffnen wir über Rechtsklick – Untersuchen die Entwicklertools.
In dem Reiter Elements suchen wir mit der Standard Tastaturkombination STRG+F nach dem Wort hidden (dt. 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 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.
Für diesen Angriff müssen wir uns als Benutzer anmelden. Hierzu klicken wir oben rechts auf Account und wählen Login aus.
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.
Nach erfolgreicher Anmeldung rufen wir unseren Warenkorb Your Basket auf.
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.
Lasst uns diese doch mal verändern.
Dazu starten wir die Interception in Burp Suite und rufen den Warenkorb Your Basket erneut auf.
Im dem GET Request vom Warenkorb Aufruf können wir, wie im ersten Angriff, die Paramenter oder Felder manipulieren.
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.
Unser Warenkorb ist nun ein anderer. Und wieder liegt eine Broken Access Control vor.
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.
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.
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.
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.
Unsere letzte Challenge.
Das Vorgehen am Anfang ist aber dasselbe. Wir führen die Aktion, welche wir testen oder manipulieren wollen, einmal aus.
Das heißt, wir legen ein Produkt in unseren Warenkorb. Wir haben uns für die Fruit Press entschieden.
Danach schauen wir uns den Vorgang in der HTTP history an. In dem POST Request stellen wir fest, dass eine BasketID übergeben wird.
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.
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.
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.
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:
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.
