Kapitel 24:
Web-Hacking – OWASP Top 10

Mittlerweile stecken wir knietief im Thema »Web-Hacking«. In diesem Kapitel lernen Sie nun die wichtigsten Angriffsvektoren auf Webanwendungen kennen. Dazu werden wir uns mit OWASP‌, dem Open Web Application Security Project (http://www.owasp.org) auseinandersetzen. OWASP ist eine schier unerschöpfliche Quelle einschlägiger Informationen zur Sicherheit von Webanwendungen.

Das Spannende ist, dass OWASP es sich zur Aufgabe gemacht hat, die Sicherheit von Webanwendungen greifbar zu machen. Das schließt auch die Perspektive des Angreifers ein. OWASP stellt nicht nur die wichtigsten Sicherheitslücken dar, sondern zeigt auch anhand praktischer Szenarien, wie diese ganz konkret ausgenutzt werden können. Dementsprechend ist OWASP für Webentwickler, Security-Verantwortliche, aber auch Ethical Hacker eine der wichtigsten Informationsquellen und daher Gegenstand dieses Kapitels – hier die Themen:

• Einführung in die OWASP-Projekte

• WebGoat & Co. – die virtuellen Sandsäcke für das Web-Hacking-Training

• Die Top-10-Angriffe in Theorie und Praxis

• Best-Practice-Maßnahmen zum Schutz gegen die Top 10

Dankenswerterweise müssen wir für den praktischen Teil dieses Kapitels das Rad nicht neu erfinden und diverse Schwachstellen selbst aufwendig einrichten. Denn es gibt zahlreiche »Vulnerable Web Applications« (VWAs), von denen wir einige nutzen werden, um Sie mit den gängigsten Angriffsformen in der Praxis vertraut zu machen. VWAs haben bereits diverse Schwachstellen absichtlich eingebaut und sind speziell für Tests im Rahmen des Web-Hacking präpariert worden.

24.1   Einführung in die OWASP-Projekte

OWASP ist eine Non-Profit-Organisation, deren Ziel es ist, die Sicherheit von Software zu verbessern. Dieses Ziel soll durch Visualisierung der Wirkung von Angriffen und deren Verteidigung erreicht werden. Dies soll quasi jedermann zugänglich gemacht werden und herstellerunabhängig geschehen.

OWASP ist in diverse Unterprojekte aufgeteilt. Die »Flagship Projects« sind auf der Projektseite aufgelistet, wie in Abbildung 24.1 dargestellt.

Es handelt sich um Angriffstools, Dokumentationen, Templates, Frameworks, Code-Projekte und mehr. Schauen wir uns ein paar wichtige an.

Abb. 24.1: Die wichtigsten Projekte von OWASP

24.1.1   OWASP Juice Shop‌

Wenn Sie »Juice Shop« wörtlich ins Deutsche übersetzen, was kommt dabei heraus? Richtig: »Saftladen«. Und genau dieser Begriff ist auch der Hintergrund der VWA Juice Shop. Das Projekt wird federführend vom aus Hamburg stammenden Björn Kimminich entwickelt und im Rahmen des OWASP-Projekts – natürlich kostenfrei als Open Source – bereitgestellt.

Der Juice Shop präsentiert sich als umfangreicher Online-Shop für – oh Wunder – Säfte und allerlei Fanartikel. Was auf den ersten Blick eine gut funktionierende Online-Plattform ist, entpuppt sich bei genauerem Hinsehen als ein Sammelsurium an Programmier- und Logikfehlern, auf die ein versierter Angreifer nur gewartet hat. Dementsprechend lädt der Juice Shop zum fröhlichen Hacken ein. Die Plattform wurde komplett in JavaScript entwickelt und nutzt zahlreiche JavaScript-Frameworks und -Technologien, wie AngularJS, NodeJS und so weiter. Abbildung 24.2 zeigt die Architektur der Anwendung, wie sie auf der OWASP-Webseite dargestellt wird. Wir gehen hier nicht auf alle Details ein.

Der Juice Shop läuft unter Windows, Linux und macOS und bietet eine tolle Möglichkeit, die eigenen Hacking-Fähigkeiten zu trainieren und weiterzuentwickeln. Hinzu kommt, dass Björn Kimminich auf der Projektseite seinen Official Companion Guide auf https://pwning.owasp-juice.shop/ bereitstellt, ein E-Book, in dem zum einen die Schwachstellen des Juice Shops vorgestellt und Hinweise zum Exploit gegeben werden und zum anderen sogar Komplettlösungen angeboten werden, wenn der angehende Ethical Hacker nicht weiterkommt. Derzeit existieren bereits über 70 Hacking-Challenges – von sehr einfach bis fast unknackbar. Möchten Sie einen Blick auf die aktuelle Version werfen, finden Sie diese auf http://demo.owasp-juice.shop. Hier werden Sie vermutlich schnell feststellen, dass der Autor durchaus Sinn für Humor hat.

Abb. 24.2: Die Architektur des Juice Shop (Quelle: Björn Kimminich, owasp.org)

24.1.2   OWASP ModSecurity Core Rule Set (CRS)

Dieses Code-Projekt stellt für die freie Web Application Firewall ModSecurity und kompatible WAFs ein Basis-Regelwerk zur Verfügung, das gegen diverse gängige Web-Angriffe schützen soll. ModSecurity kann unter anderem als Modul in den Apache-Webserver integriert werden und filtert eingehende Anfragen gemäß dem konfigurierten Regelwerk. Der Schutz umfasst SQL-Injection, XSS-Angriffe, Local File Inclusion und vieles mehr. Besonderer Wert wird darauf gelegt, möglichst wenige False Positives zu generieren.

24.1.3   OWASP Web Security Testing Guide

Mit dem Testing Guide wird ein umfangreicher Leitfaden für das Testen von Webanwendungen bereitgestellt. Hervorzuheben ist, dass die Testphase bereits in der Entwicklung der Software beginnt und damit den gesamten Zyklus der Software-Entwicklung berücksichtigt.

Der Penetration-Testing-Bereich ist dabei nur ein Teil der Test-Empfehlungen. Genau genommen weist der Leitfaden darauf hin, dass in dieser Phase das Kind schon in den Brunnen gefallen ist und daher unbedingt früher im Rahmen der Entwicklung der Anwendung mit entsprechenden Validierungs- und Sicherheitstests begonnen werden muss.

Letztlich ist der OWASP Testing Guide ein sehr wertvoller Leitfaden für Sicherheitsverantwortliche und Ethical Hacker, um Webanwendungen professionell und systematisch auf Schwachstellen zu testen.

24.1.4   OWASP Top 10

‌Last, but not least kommen wir im Rahmen der OWASP-Projekte auf die Top-10-Liste der wichtigsten Angriffsformen auf Webanwendungen, diese ist unterteilt in die Sektionen A1 bis A10. Sie wurde 2021 aktualisiert und stellt eine Einschätzung von diversen Experten dar, welche Schwachstellen am häufigsten ausgenutzt werden.

Die OWASP Top 10 dient Planern, Webentwicklern, Sicherheitsverantwortlichen und Penetration-Testern als Referenz für die Entwicklung von sicheren Webanwendungen inklusive Tests hinsichtlich des Erfolgs der getroffenen Absicherungsmaßnahmen. Auch wenn die Top-10-Liste bei Weitem nicht alle relevanten Angriffsformen umfasst, stellt ihre Beachtung doch einen guten ersten Schritt hin zu einer sicheren Webanwendung dar. Andersherum sollten Penetration-Tester Angriffe auf die Top-10-Schwachstellen priorisieren, um sicherzustellen, dass hier keine elementaren Sicherheitslücken vorhanden sind. Aus diesem Grund werden wir uns im weiteren Verlauf dieses Kapitels im Detail mit den OWASP Top 10 beschäftigen.

24.2   WebGoat & Co – virtuelle Sandsäcke für das Web-Hacking-Training

Bevor Sie nun aufs Geratewohl die Ärmel hochkrempeln und im Internet nach Opfern suchen, sollten wir Sie an die ethischen Grundsätze unserer Tätigkeit erinnern. Es ist verboten, Schwachstellen in fremden Systemen auszunutzen, und selbst, wenn Sie dies tun, um anschließend den verantwortlichen Administrator über die Schwachstelle in seinem System zu informieren, haben Sie strafrechtlich ganz klar eine rote Linie überschritten. Leider ist es auch in der Praxis so, dass an Unternehmen gemeldete Schwachstellen nicht selten in einer Anzeige enden, statt in einer Dankesbekundung.

Hinweis: Legales Hacking fremder Systeme

Angriffe auf fremde, geschützte Software und Computersysteme sind grundsätzlich nicht erlaubt. Allerdings gibt es Bug-Bounty-Programme‌, die Software-Hersteller, Unternehmen oder andere Organisationen ins Leben rufen, um neugierigen Hackern, die gern nach Schwachstellen suchen, eine legale Alternative anzubieten. Dabei entsteht eine Win-win-Situation: Hacker in aller Welt suchen nach Schwachstellen in Programmen und Systemen der betreffenden Software und Plattformen und informieren die Hersteller oder Betreiber exklusiv und vertraulich über die gefundenen Sicherheitslücken. Im Gegenzug erhalten sie teils hohe Prämien.

Bleibt also die Frage, wie wir in unserem Rahmen an freiwillige Opfer gelangen. Glücklicherweise müssen Sie sich nicht erst zum Web-Programmierer weiterentwickeln und eine eigene Opfer-Anwendung programmieren. Stattdessen können Sie auf eine der zahlreichen VWAs zurückgreifen, die nur darauf warten, von Ihnen als Sandsack für Ihr Web-Hacking-Training eingesetzt zu werden. Sie haben hier tatsächlich eher die Qual der Wahl. Nachfolgend stellen wir Ihnen ein paar wichtige vor.

Ausgenommen WebGoat können viele der hier vorgestellten VWAs als eigenes Verzeichnis unter dem DocumentRoot-Verzeichnis als Webanwendung bereitgestellt werden, also z.B. folgendermaßen:

• /var/www/html/mutillidae

• /var/www/html/bwapp

• /var/www/html/dvwa

Wir empfehlen Ihnen, diese VWAs im Apache-Webserver des Linux-Servers Ihres Labs (192.168.1.213) zu installieren. Alternativ können Sie sie auch direkt auf dem Kali-Linux-System installieren. Zum einen werden wir einige der Anwendungen im weiteren Verlauf des Themas »Web-Hacking« zu Demonstrationszwecken nutzen und zum anderen können Sie damit ein wenig Erfahrung in der Bereitstellung von Webanwendungen sammeln. Eine detaillierte Anleitung hierzu finden Sie unter https://www.hacking-akademie.de/buch/member.

24.2.1   WebGoat

WebGoat ist ein OWASP-Projekt, das als Lehrmittel für Web-Hacking-Trainings konzipiert ist. Sie haben die »Web-Ziege« ja bereits in Kapitel 18 Session Hijacking eingerichtet und kennengelernt. Sie können die Software unter https://github.com/WebGoat/WebGoat/releases herunterladen. Im Gegensatz zu den anderen hier vorgestellten VWAs basiert WebGoat auf Java. Sie können es gleichermaßen unter Linux, macOS oder unter Windows betreiben. Wir gehen davon aus, dass Sie WebGoat wie alle die anderen VWAs auf dem Linux-Server oder auf Ihrem Kali Linux-System selbst bereitstellen.

Die Version 8 wurde deutlich umgebaut und jede Lektion ist jetzt nach folgendem Schema aufgebaut:

• Erklärung zur Schwachstelle

• Aufgaben, in denen Sie erfahren, wie Sie die Sicherheitslücke ausnutzen können

• Erläuterungen zur Absicherung der Schwachstelle

Damit ist WebGoat seit der Version 8 nicht mehr eine reine Hacking-Plattform, sondern eine Lehrplattform zum Studieren der Schwachstellen und deren Vermeidung. Das prädestiniert sie natürlich für unsere Zwecke, da sie für einzelne Lektionen sowie als Ergänzung zum Buch genutzt werden kann. Weiterhin bildet sie bereits als eine der wenigen VWAs die OWASP Top 10 in der Version 2021 ab.

Wichtig: WebGoat ist kein Ersatz für ein Web-Hacking-Training!

Wer jetzt davon ausgeht, dass er nur WebGoat starten muss und sich als Anfänger durch die Lektionen klicken kann, wird recht schnell feststellen, dass es teilweise einiges an Vorwissen zu den jeweiligen Webtechnologien erfordert, da die Informationen nicht immer umfassend aufbereitet und erläutert dargestellt werden.

Mit WebWolf‌ ist ein neues, zunächst optionales Modul für WebGoat hinzugekommen, das die Angriffsseite repräsentiert und z.B. die Analyse von HTTP-Requests ermöglicht, ähnlich wie Burp Suite oder ZAP. WebWolf wurde entwickelt, um zu verdeutlichen, welche Aktionen in der Identität des Benutzers und welche als Angreifer stattfinden. Mittlerweile ist WebWolf in die WebGoat eingeflossen.

WebGoat und WebWolf basieren auf Java und sind damit plattformübergreifend einsetzbar. Da wir Ihnen WebGoat bereits vorgestellt haben, gehen wir auf die Bereitstellung an dieser Stelle nicht weiter ein, kommen aber auf die Plattform noch zurück.

24.2.2   Mutillidae II

Der Begriff »Mutillidae« ist lateinisch und bedeutet Ameisenwespe. Mit Mutillidae II‌ stellt OWASP einen weiteren Vertreter der VWAs vor, der sowohl in Metasploitable enthalten ist als auch in anderen integrierten VWA-Plattformen. Da Mutillidae häufig aktualisiert wird, ist allerdings in Metasploitable nur eine veraltete Version enthalten.

Möchten Sie mit Mutillidae in der aktuellen Version arbeiten, so kommen Sie nicht umhin, diese in einer LAMP- oder XAMPP-Umgebung einzurichten. Auf der OWASP-Projektseite ist ein Link zu github.com enthalten (https://github.com/webpwnized/mutillidae), wo Sie die Dateien über git klonen können. Dort finden Sie zudem einen Link zum YouTube-Kanal des Projekts (https://www.youtube.com/user/webpwnized), auf dem Sie detaillierte Video-Tutorials erhalten, wie Sie Mutillidae II auf einem Ubuntu-Linux (und damit auch auf einem Debian-Linux) zum Laufen bringen können.

Das Besondere an Mutillidae II ist, dass nicht nur diverse Schwachstellen präsentiert und zum Testen bereitgestellt werden, sondern die Anwendung sich direkt an den OWASP Top 10 orientiert (vgl. Abbildung 24.3). Zu jeder Top-10-Schwachstelle wird mindestens ein, meistens aber mehrere Beispiele gebracht und diverse Zusatzmaterialien bereitgestellt.

Abb. 24.3: Mutillidae II orientiert sich an den OWASP Top 10.

Daher ist es auch wichtig, die aktuelle Version zu nutzen, da in älteren Versionen, wie z.B. in Metasploitable, die Top-10-Schwachstellen von 2017 noch nicht enthalten sind. Bislang wurde noch nicht auf 2021 umgestellt. Auch auf Mutillidae werden wir noch näher eingehen.

24.2.3   bWAPP

Das Wort »bWAPP« steht für buggy web application und bezeichnet eine freie, PHP-basierte VWA aus dem ITSEC-GAMES-Projekt (also ausnahmsweise mal nicht OWASP), die unter WAMP/LAMP und XAMPP läuft oder alternativ unter dem Namen Bee-Box als komplette VM unter https://sourceforge.net/projects/bwapp bzw. https://sourceforge.net/projects/bwapp/files/bee-box heruntergeladen werden kann.

Die Anwendung enthält über 100 Bugs und Vulnerabilities. Haben Sie sich bei bWAPP z.B. mit den Default-Credentials bee/bug angemeldet, so können Sie aus einer Liste auswählen, welche Web-Hacking-Herausforderung Sie angehen möchten, wie Abbildung 24.4 zeigt.

Abb. 24.4: bWAPP stellt die Herausforderungen als Liste bereit.

Auch hier haben sich die Entwickler wieder an den OWASP Top 10 orientiert und die Schwachstellen nach den Top 10 (A1 bis A10) sortiert. Über das Setzen des Security-Levels kann die Schwierigkeitsstufe angepasst werden. Im Unterschied zu den bisher vorgestellten VWAs handelt es sich bei bWAPP um eine reine Übungsplattform mit Herausforderungen, die zwar einem Thema zugeordnet sind, sodass der Angreifer grundsätzlich weiß, in welche Richtung er schauen muss, aber keine Tipps oder Lösungen erhält. So ist bWAPP eine großartige Möglichkeit zum Üben, wenn Sie den Angriff zunächst grundsätzlich verstanden haben und nun eine Herausforderung suchen.

Vorsicht! Malware-Warnung

Zum aktuellen Zeitpunkt (Oktober 2023) warnt https://sourceforge.net davor, bWAPP-Files herunterzuladen, und gibt eine Malware-Warnung aus. Wir können dies aktuell nicht einschätzen, empfehlen aber, hier sehr vorsichtig vorzugehen. Die VWA bWAPP wird aber auch auf github von verschiedenen Usern angeboten.

24.2.4   DVWA

»DVWA‌« steht für Damn Vulnerable Web Application – und nomen est omen. Es handelt sich um eine weitere freie und auf PHP/MySQL basierende Webanwendung, die als Trainingsplattform für das Web-Hacking gedacht ist. Die Software ist unter https://github.com/digininja/DVWA erhältlich. Sie bietet eine übersichtliche Oberfläche und ermöglicht für die gängigsten Angriffe jeweils eine Webseite, auf der sich der angehende Hacker ausprobieren kann. In fast allen Fällen sind mehrere Links zu weiterführenden Informationen enthalten, die eine tiefer gehende Beschäftigung mit der jeweiligen Schwachstelle ermöglichen. Abbildung 24.5 zeigt ein Beispiel.

Abb. 24.5: DVWA bietet Trainingsmöglichkeiten für diverse, gängige Web-Angriffe.

Im Gegensatz zu anderen Plattformen ist die Anzahl der Angriffsszenarien eingeschränkt und die Form der Angriffe teilweise auch schon etwas in die Jahre gekommen. Dennoch eignet sich DVWA sehr gut als ergänzende Übungsplattform und sollte in keinem Web-Hacking-Lab fehlen.

24.2.5   Web Security Dojo

Ähnlich wie bWAPP wird auch das Web Security Dojo unter‌ (https://www.mavensecurity.com/resources/web-security-dojo) als Open-Source-VM in Form einer OVA-Datei bereitgestellt. Das Dojo (japanisch für Trainingsraum) integriert diverse Tools, wie z.B. DVWA, Mutillidae oder Juice Shop, und liefert viele Security-Analyse-Tools mit. Dazu gehören die Burp Suite, Zed Attack Proxy, Metasploit, Nikto, Skipfish und viele andere.

Abb. 24.6: Das Web Security Dojo als virtuelle All-In-Maschine

Das Projekt ist halbwegs aktuell, wird noch gepflegt und ist damit auf jeden Fall einen Blick wert.

24.2.6   Vulnhub und Pentesterlab

Etwas außerhalb der Konkurrenz laufen die Plattformen https://vulnhub.com und https://pentesterlab.com. Hier finden Sie diverse virtuelle Maschinen mit bewusst eingebauten Schwachstellen jeglicher Art. Vulnhub ist eine komplett freie Ressource, während das bereits bekannte Pentesterlab eine bezahlpflichtige Pro-Variante anbietet, bei der erweiterte Pentesting-Lektionen und Support inbegriffen sind.

Beide Plattformen sind eine ergiebige Quelle zum Üben von Hacking-Methoden und Penetrationstests. Die bereitgestellten virtuellen Maschinen sind in der Regel sehr klein und schnell einsetzbar. Es handelt sich oft um einzelne, spezielle Schwachstellen, ähnlich wie Shellshock aus dem vorigen Kapitel und weniger um umfassende Anwendungen mit didaktisch aufbereiteten Webseiten, die gezielt bearbeitet werden können. Als Trainingsmaterial sind die VMs und das Begleitmaterial jedoch perfekt geeignet. Wenn Sie ein wenig suchen, werden Sie auch noch viele weitere Angebote in dieser Richtung im Internet finden. Auch in der Hacking-Akademie bieten wir viele Web-Hacking-Herausforderungen an, um unter anderem die hier gezeigten Angriffstechniken zu üben und zu analysieren (https://hacking-akademie.de).

Tipp: Capture the Flag – Hacking als Sport

Falls Sie darüber hinaus an Hacking-Spielen und Wettkampf interessiert sind, sollten Sie sich mit Capture the Flag (CTF) beschäftigen. Geben Sie in der Suchmaschine Ihrer Wahl einfach »ctf hacking« ein, um in eine ganz neue Welt einzutauchen. Es gibt diverse Beiträge, Plattformen und Veranstaltungen zu diesem Thema. Natürlich finden Sie auch im Angebot der Hacking-Akademie diverse CTF Challenges.

24.3   Die OWASP Top 10 in der Übersicht

Die Top-10-Sicherheitsrisiken werden von OWASP‌ bereits seit vielen Jahren gepflegt und regelmäßig aktualisiert. Nach 2017 wurde 2021 eine aktuelle Liste mit Bedrohungen veröffentlicht. Demnach haben sich einige Änderungen in den Top 10 ergeben, wie Abbildung 24.7 zeigt.

Abb. 24.7: Die Änderungen in der OWASP-Top-10-Liste

Die Schwachstellen werden mit A01 bis A10 bezeichnet. Wir werden in diesem Kapitel alle Punkte der Top-10-Liste erwähnen. In der Grafik sind die Bewegungen durch Pfeile zu erkennen. Es gab einige Umbenennungen, um die Grundursache und nicht nur das Symptom zu bezeichnen. Einige Punkte aus 2017 sind herausgefallen, einige wurden umgestellt und ggf. umbenannt sowie erweitert, und wieder andere sind neu hinzugekommen, wie in der Grafik zu sehen.

Dabei ist zu berücksichtigen, dass jedes Unternehmen und jede Organisation eine unterschiedliche Ausgangslage hat und die Gewichtungen daher nicht überall identisch sein können. Eine Schwachstelle, die in einem Unternehmen zu einer existenziellen Bedrohung führen kann, ist für ein anderes Unternehmen evtl. nur eine Randerscheinung, die keinen größeren Schaden verursachen kann. Trotzdem sollte jeder Sicherheitsverantwortliche sehr genau prüfen, inwieweit seine Organisation von der jeweiligen Schwachstelle betroffen sein könnte. Werfen wir also einen eingehenden Blick auf die Schwachstellen der OWASP Top 10 2021.

24.4   A01 – Broken Access Control

Diese Schwachstelle (dt. Fehlerhafte Zugriffskontrolle) wurde in die Top-10-Version von 2017 aufgenommen und ist in der Version 2021 von Platz 5 auf Platz 1 aufgestiegen. Damit ist sie aktuell wohl das schwerwiegendste Sicherheitsrisiko in Webanwendungen. Bei der Zugriffskontrolle werden Richtlinien erzwungen, sodass die Benutzer nicht außerhalb ihrer vorgesehenen Berechtigungen handeln können. Ist die Zugriffskontrolle nicht korrekt implementiert, führt das ggf. zur unbefugten Offenlegung, Änderung oder Zerstörung von Daten.

Die Schwachstelle A01 steht nicht komplett isoliert da. Wie auch an anderen Stellen finden sich Überschneidungen mit anderen Schwachstellen der Top-10-Liste, z.B. mit A07 – Identification and Authentication Failures. Andererseits unterscheiden wir zwischen der Authentifizierung des Benutzers durch die Webanwendung und der anschließenden Autorisierung aufgrund seiner Identität. Die Autorisierung ist die eigentliche Zugriffskontrolle. Sie besagt zum Beispiel, dass der Benutzer Bob auf das Verzeichnis /projekt4711 lesend und schreibend zugreifen kann, Alice jedoch nicht. Dafür hat Alice auf ein Management-System Admin-Zugriff, Bob darf dort jedoch nur Read-Only zugreifen.

Kann ein Angreifer die Zugriffskontrolle umgehen oder so manipulieren, dass er erhöhte Rechte erhält, so ist es ihm möglich, Daten zu stehlen, zu manipulieren oder zu löschen. Dies ermöglicht ihm häufig weiterführende Angriffe, z.B. wenn er Zugangsinformationen zu weiteren Systemen im Netzwerk erhält.

24.4.1   Unsichere direkte Objektreferenzen

Unter diesem Begriff (gängig als IDOR‌ für Insecure Direct Object Reference abgekürzt) verstehen wir eine Referenzierung auf ein internes Objekt, z.B. eine Datei oder einen Datensatz einer Datenbank, der ohne ausreichenden Schutz dem Angreifer zugänglich gemacht wird. So wäre z.B. eine Benutzer-ID eine solche Referenz auf den Benutzerdatensatz. Wie Sie in Abschnitt 24.10.2 sehen werden, kann durch die Manipulation der UID in einem Session-Cookie die Identität des Benutzers geändert werden, sodass ein normaler Benutzer eric plötzlich zum Benutzer admin wird. Dies ist tatsächlich schon ein Beispiel für IDOR.

Eine andere Form von IDOR ist das Einbinden von lokalen Dateien in den PHP-Code. Dies bezeichnen wir als File Inclusion. Wir unterscheiden zwischen Local File Inclusion (LFI)‌ und Remote File Inclusion (RFI). Nachfolgend betrachten wir ein Beispiel für LFI.

PHP unterstützt mit den Funktionen include, include_once, require und require_once das Importieren von externen Inhalten in das PHP-Skript. Wird eine Datei angegeben, so liest PHP den Inhalt dieser Datei aus und bindet ihn ein. Handelt es sich um PHP-Code, wird das Skript um den externen Code ergänzt. Dies kann vom Entwickler genutzt werden, um den PHP-Code dynamischer zu gestalten bzw. eine bessere Struktur in die Code-Dateien der Webanwendung zu bekommen.

Gelingt es nun einem Angreifer, eine von ihm manipulierte, lokale Datei auf dem Server mit PHP-Code einzubinden, kann er das serverseitige PHP-Skript nach Belieben ändern. Doch so weit muss der Angreifer oft gar nicht gehen. Im einfachsten Fall werden die Daten aus der Datei einfach ausgegeben. Schauen wir uns das in Mutillidae einmal an.

Als Voraussetzung stellen Sie bitte sicher, dass auf dem Webserver, auf dem Mutillidae läuft, in /etc/php/7.3/apache2/php.ini (die PHP-Version muss ggf. angepasst werden!) die folgenden Werte gesetzt sind:

allow_url_fopen = On
allow_url_include = On 

Haben Sie die Änderung vorgenommen, müssen Sie den Webserver anschließend neu starten:

sudo systemctl restart apache2 

Wechseln Sie in Mutillidae auf die Local File Inclusion-Schwachstelle unter A5, wie in Abbildung 24.8 gezeigt. Bitte nicht irritieren lassen: In der 2017er Version fiel diese Schwachstelle ja noch unter A5 und nicht A1.

Abb. 24.8: Local File Inclusion (Titel: Arbitrary File Inclusion)

Wie zu erkennen, wird in der URL explizit eine PHP-Datei aufgerufen. Da wäre es doch sehr interessant zu sehen, was beim Aufruf anderer Dateien passiert. Testen wir es mit /etc/passwd, registrieren wir bereits einen vollen Erfolg (siehe Abbildung 24.9).

Abb. 24.9: Wir binden den Inhalt von /etc/passwd in die Ausgabe von index.php ein.

Offensichtlich prüft das Skript index.php nicht ausreichend, welcher Wert in der Variablen page enthalten ist, und bindet die angegebene Datei ohne Weiteres mit ein. Wäre jetzt PHP-Code in der Datei integriert, so könnte der Angreifer sogar einen Shell-Zugriff erhalten. Wir knüpfen später daran an und stellen Ihnen die Varianten Local File Inclusion (LFI) und Remote File Inclusion (RFI) noch etwas genauer vor.

24.4.2   Fehlerhafte Autorisierung auf Anwendungsebene

Bei dieser Schwachstelle (engl. Missing Function Level Access Control) geht es in erster Linie um das Aufdecken und Ausnutzen versteckter Funktionalität. Das bedeutet, dass z.B. ein normaler Benutzer ohne besondere Privilegien auf eine Admin-Seite im Backend zugreifen kann, obwohl dies natürlich nicht vorgesehen ist. Er muss dafür lediglich die richtige URL aufrufen. Die folgende URL wird zum Beispiel verwendet, um normalen, authentifizierten Benutzern ihre Seite anzuzeigen:

https://webshop.tld/webapp/standarduser_page

Dagegen erhält ein Benutzer mit Admin-Privilegien die folgende Seite:

https://webshop.tld/webapp/admin_page

So weit, so gut. Problematisch wird es, wenn ein normaler Benutzer bei manuellem Aufruf der Admin-URL ebenfalls auf die Administratorseite gelangt, ohne dass seine Zugriffsberechtigung geprüft wird. Hier fehlt dann die Autorisierungsprüfung und die Schwachstelle »Missing Function Level Access Control« ist vorhanden. Der Benutzer muss lediglich herausfinden, dass diese Seite existiert. Dies kann z.B. durch Webcrawling oder Brute Force geschehen. Mit DirBuster haben Sie im vorhergehenden Kapitel bereits ein Tool kennengelernt, das auf derartige Angriffe spezialisiert ist.

Dahinter verbirgt sich in einigen Fällen die Überlegung, dass das, was versteckt ist, nicht gefunden werden kann und daher sicher ist. Aber der Ansatz security through obscurity (zu Deutsch etwa: Sicherheit durch Unklarheit) funktioniert in den seltensten Fällen und sollte keine Grundlage für das Sicherheitskonzept sein. Schauen wir uns dazu ein Beispiel aus der WebGoat in der Version 8.0.0 M25 (oder eine höhere 8er Version) an:

Öffnen Sie zunächst WebGoat – wenn auf dem Linux-Server gestartet, über Eingabe von http://192.168.1.213:8080/WebGoat im Browser. Unter (A5) Broken Access Control|Mission Function Level Access Control finden Sie unter Punkt 2 eine Übung mit dem Titel Relying on Obscurity. Hier gilt es, den Quellcode des angezeigten Menüs zu analysieren und die zwei versteckten Items zu identifizieren, die für Sicherheit sorgen sollen, in der Hoffnung, dass sie nicht im HTML-Code entdeckt werden.

Das Menü besteht aus den Hauptpunkten Account und Messages. Klicken Sie auf einen dieser Punkte, so öffnen sich jeweils die Untermenüs. Klicken Sie nun rechts auf einen der Menüpunkte unter Messages und wählen Sie z.B. im Browser Firefox Inspect Element, wie in Abbildung 24.10 dargestellt. Jeder moderne Browser hat eine Quellcode-Analyse-Funktion, die häufig über das Kontextmenü oder die Funktionstasten (z.B. F12) aufgerufen werden können. Im Chrome heißt diese Funktion beispielsweise Untersuchen, also ganz ähnlich.

Abb. 24.10: Ein Element der Webseite untersuchen

Auch wenn Sie kein Experte in der Webprogrammierung sind, können Sie mit gesundem Menschenverstand und scharfem Hinsehen sowie minimalen Englischkenntnissen (hidden = versteckt) die gesuchte Schwachstelle finden. Der Inspector in Firefox erleichtert Ihnen zudem die Arbeit, indem er die inaktiven Elemente in Grau darstellt. Klappen Sie über den kleinen Pfeil links alle Unterstrukturen auf. Dort finden Sie eine H3-Überschrift der Klasse hidden-menu-item menu-header und hier den versteckten Menüpunkt Admin, wie in Abbildung 24.11 zu sehen.

Abb. 24.11: Die versteckten Elemente

Hier findet sich eine Liste mit Hyperlinks (<a href=) zu den Webseiten /users und /config. Diese werden als Elemente Users und Config dargestellt. Tragen Sie diese in die Lösungsfelder ein, erhalten Sie ein positives Feedback (siehe Abbildung 24.12).

Abb. 24.12: Aufgabe gelöst, weiter geht’s!

Wozu ist es nun wichtig, derartige Elemente zu identifizieren? In einigen Fällen können versteckte Elemente genutzt werden, um an andere Informationen zu gelangen. In diesem Fall haben wir durch Analyse des Seiten-Quellcodes erfahren, dass ein Verzeichnis /Users und ein Verzeichnis /Config existieren. Beides klingt vielversprechend.

Hierzu erhalten wir in der Bestätigungsnachricht einen Hinweis, dass eine der URLs im nächsten Lab (Punkt 3) mit dem Titel Just Try It nützlich sein wird. Hier ist allerdings wirklich Erfahrung und Trial and Error notwendig. Falls Sie sich an dieser Übung versuchen wollen, hier einige Hinweise: Normalerweise gibt GET /WebGoat/Users HTTP/1.1 nur die Anzahl an registrierten Benutzern aus, das bringt uns nicht weiter.

Es gibt zwei verschiedene Wege, um den gesuchten Hashwert gemäß der Aufgabe zu finden. Betrachten wir den »einfachen«: Er besteht darin, über die Repeater-Funktion in der Burp Suite den Request GET /WebGoat/users HTTP/1.1 so zu manipulieren, dass er keine HTML-Anfrage, sondern eine Anfrage nach einer JSON-Anwendung ist. Abbildung 24.13 zeigt die Anfrage und das Ergebnis.

Abb. 24.13: Den Hashwert über den Content-Type ermitteln

Durch die Änderung des Requests können wir die Webanwendung dazu bringen, eine völlig andere Art von Antwort zu geben, die vertrauliche Informationen enthält und in diesem Fall unter anderem einen Hashwert ausgibt, der dem Benutzeraccount zugeordnet ist. Unter dem Strich werden in allen Fällen die Zugriffsrechte nicht oder nur unzureichend geprüft, sodass der Angreifer, ohne sich authentifizieren zu müssen, an die Informationen herankommt.

Tipp: Geduld, Ausdauer und Hartnäckigkeit sind gefragt!

Wie Sie sehen, erfordert professionelles Web-Hacking fundierte Kenntnisse in diversen Technologien (hier speziell: HTTP-Header-Manipulation, Content-Types und JSON) und ggf. auch eine gehörige Portion Geduld und Durchhaltevermögen, um eine Schwachstelle zu finden. Geben Sie sich Zeit, um in die Materie hineinzuwachsen, und erwarten Sie nicht, in zwei Wochen zum Web-Hacking-Spezialisten zu mutieren – dazu ist die Materie zu komplex.

24.4.3   Schutzmaßnahmen

Wie Sie gesehen haben, sollten Zugriffsberechtigungen immer auf dem Server festgelegt und geprüft werden, niemals auf dem Client, damit der Angreifer die verwendeten Metadaten nicht manipulieren kann. Hierbei sprechen wir von trusted server-side code. In diesem Fall wurde nicht korrekt überprüft, welche Art von Daten angefordert werden dürfen (HTML ist nicht gleich JSON).

Das Prinzip security through obscurity funktioniert nicht zuverlässig. Daher sollten Ressourcen, die nicht für alle User verfügbar sein sollen, auch nur explizit nach der Autorisierungsprüfung bereitgestellt werden. Das einfache Deaktivieren, »Ausgrauen« oder Verstecken kann leicht umgangen werden.

Zugriffskontrollmechanismen sollten nur einmal (serverseitig) implementiert werden und an den entsprechenden Stellen zum Einsatz kommen. Eine effektive Zugriffsregelung erfordert ein fundiertes Berechtigungskonzept, das im Rahmen der Qualitätssicherung genau getestet werden sollte – nicht mittels SAST oder DAST, sondern manuell! Dabei muss jede Ressource berücksichtigt werden.

Generell gilt: Deny by Default, also Whitelisting. Grundsätzlich darf niemand auf Ressourcen zugreifen, bis die Berechtigungen explizit gesetzt wurden. In diesem Zusammenhang sollte das Konzept der Least Privileges eingesetzt werden. Jeder Anwender hat nur genau die Berechtigungen, die er für seine Tätigkeit benötigt, nicht mehr. Fehlerhafte Zugriffsversuche und Logins sollten protokolliert und entsprechende Warnungen via E-Mail, Popup, SMS oder Ähnlichem generiert werden. Rate Limiting hilft hierbei, Brute-Force- bzw. Wörterbuch-Angriffe zu unterbinden. Ein Ticketsystem hilft bei der Organisation.

Vorsicht: Die Geister, die ich rief ...

So gut und richtig die oben genannten Maßnahmen sind, so herausfordernd kann es in der Praxis sein, sie umzusetzen. Hierbei muss immer die Verhältnismäßigkeit gewahrt bleiben. In größeren Umgebungen kann es sonst leicht passieren, dass viele False Positives gemeldet werden und die wirklich wichtigen Ereignisse untergehen.

Auch die Granularität der Zugriffsrechte muss im Verhältnis zum Aufwand stehen. Blickt der Administrator nicht mehr durch, entstehen Fehler. Eine gut geplante Benutzerverwaltung, überschaubare Berechtigungsgruppen über entsprechende Rollen und eine IAM-Software (IAM = Identity & Access Management) ermöglichen eine strukturierte Benutzerverwaltung.

24.5   A02 – Cryptographic Failures

Diese Schwachstelle wurde in der in den OWASP Top 10 2017 noch als Sensitive Data Exposure (zu Deutsch: Verlust der Vertraulichkeit sensibler Daten) bezeichnet und beinhaltet einen Perspektivenwechsel. Sie zielt nicht auf eine bestimmte Angriffstechnik ab, sondern auf die Gefahr, dem Angreifer unabsichtlich sensible Daten preiszugeben. An dieser Stelle bezieht sich die Schwachstelle auf Fehler in der kryptografischen Absicherung der Daten.

24.5.1   Welche Daten sind betroffen?

A02 – Cryptographic Failures betrachtet die Frage, ob es einem Angreifer möglich ist, Daten wie Passwörter, Kreditkartendaten, Patientendaten oder auch Geschäftsgeheimnisse zu stehlen. Welche Daten konkret betroffen sind, bestimmen unter anderem auch Verordnungen, wie die allseits geliebte Datenschutz-Grundverordnung (DSGVO) oder der PCI Data Security Standard (PCI DSS), der im Zahlungsverkehr zum Einsatz kommt.

Problematisch ist, dass häufig mehr Daten als notwendig erfasst werden. Jede zusätzliche Information über einen Benutzer beinhaltet auch ein erhöhtes Risiko, dass diese Daten gestohlen werden können.

Während persönliche Daten der Kunden unter besonderem Schutz stehen, vernachlässigen Unternehmen in einigen Fällen den Schutz ihrer eigenen, sensiblen Firmendaten. So findet sich z.B. eine Liste mit Personaldaten auf dem Webspace oder das Backup von Anwendungen wird dort platziert, um es von dort via HTTP(S) zu seinem Bestimmungsort zu transportieren. Diese Dateien können von Web-Spidern gefunden werden und werden dann auch bei entsprechenden Suchanfragen (Stichwort: Google-Hacking) angezeigt.

Bei der Speicherung der Daten ist es auch wichtig, zwischen der Verschlüsselung auf dem Datenträger und der Transport-Verschlüsselung zu unterscheiden – beides ist relevant. Werden z.B. sensible Daten über sichere Verschlüsselungsalgorithmen mit einem qualitativ hochwertigen Schlüssel auf der Festplatte des Servers gespeichert, dann aber via HTTP unverschlüsselt übertragen, so ist die Kette – wie so oft – nur so stark wie ihr schwächstes Glied und der Angreifer bedankt sich, wenn er die Daten während der Übertragung mitliest. Der Häufigkeitsfall dürfte mittlerweile allerdings eher andersherum sein, dass Daten zwar gut gesichert über das Netzwerk übertragen werden, dann aber nur unzureichend auf den Endpunkten gesichert werden.

24.5.2   Angriffsszenarien

Die möglichen Angriffsszenarien umfassen diverse Techniken, die zum großen Teil nicht neu sind und sich auch innerhalb der OWASP Top 10 überschneiden. Injection-Angriffe nach OWASP A03 beschreiben z.B. gängige Vorgehensweisen, um Daten zu stehlen. In der nächsten Schwachstelle lernen Sie SQL Injection in einem Praxisbeispiel kennen. Im Ergebnis werden wir sämtliche Benutzerdatensätze erhalten, darunter auch die Kreditkarten-Nummern. Dabei spielt es keine Rolle, ob die Daten verschlüsselt gespeichert bzw. übertragen wurden oder nicht, da sie am Frontend zwangsläufig wieder in Klartext angezeigt werden und dazu entschlüsselt werden müssen.

In diesem Zusammenhang können auch Fehler in der Authentifizierung (OWASP A07) ausgenutzt werden. Wir werden in einem Beispiel zu A07 sehen, wie ein regulärer Benutzer über die Änderung seiner ID zum Administrator werden kann. Ein Benutzer, der durch Privilegien-Eskalation zum Admin wird, kann auf einer Webseite ggf. auch Daten abrufen, die einem normalen Benutzer nicht zugänglich sind. Neben dem Stehlen von Daten können diese natürlich auch manipuliert oder gelöscht werden – in jedem Fall wurden sensible Daten kompromittiert und ihre Vertraulichkeit und Integrität ist nicht mehr gegeben.

Ein weiterer Angriffsvektor entsteht durch die Implementation schwacher Krypto-Algorithmen. Wie Sie bereits wissen, ist SSL von zahlreichen Schwachstellen, wie Heartbleed, Poodle & Co. betroffen. Doch auch TLS 1.0 und 1.1 gelten nicht mehr als sicher und selbst TLS 1.2 hat bereits einige Schwachstellen, sodass nach Möglichkeit TLS 1.3 zum Einsatz kommen sollte.

Nun ist es oft gar nicht mal so, dass die neueren Algorithmen mit höherer Sicherheit vom Server nicht angeboten werden. Das Problem ist häufig der Fallback auf schwächere Algorithmen, falls der Kommunikationspartner während der Aushandlung mitteilt, dass die besseren Algorithmen nicht unterstützt werden. Dies kann von einem Angreifer provoziert werden, sodass ein moderner, TLS 1.3 unterstützender Webserver ein Downgrade auf SSL durchführt, damit die Kommunikation zumindest grundsätzlich stattfinden kann. Auf diesen schwachen Algorithmus setzt der Hacker nun einen passenden Angriff (z.B. Poodle) an und kann somit die Verschlüsselung knacken und die Daten kompromittieren. Dem können wir begegnen, in dem der Server es verweigert, ältere und schwächere TLS-Versionen zu verwenden.

Möchten Sie einmal prüfen, ob die SSL/TLS-Konfiguration Ihrer Internet-Präsenz als sicher einzustufen ist, so bietet die Webseite https://www.ssllabs.com/ssltest eine Prüfung Ihrer Website an.

Wie in Abbildung 24.14 zu erkennen, ist die Website https://www.hacking-akademie.de zwar nicht perfekt, wird aber immerhin mit A+ als sehr sicher eingestuft.

Abb. 24.14: hacking-akademie.de geprüft durch SSL Labs

24.5.3   Schutzmaßnahmen

Die wichtigste und grundlegende Maßnahme zum Schutz Ihrer Daten besteht in der Klassifizierung der Daten. Nicht alle Daten sind gleichermaßen schützenswert. So können Bilddateien, die auf Webseiten verwendet werden oder offizielle PDF-Dokumente, die zum freien Download angeboten werden, mit einer geringen Schutzklasse versehen werden. Dagegen sind personenbezogene Daten und interne Geschäftsdaten entsprechend hoch zu klassifizieren. Hier geben auch entsprechende Verordnungen, wie z.B. die DSGVO, Vorgaben, die rechtlich einzuhalten sind.

Sind die Daten klassifiziert und ihr Schutzbedarf definiert, werden passende Maßnahmen implementiert. Während technisch gesehen starke Verschlüsselungsalgorithmen mit qualitativ hochwertigen Schlüsseln den besten Schutz vor Datendiebstahl darstellen, ist die grundsätzlich beste Methode zum Schutz von Daten, sie gar nicht erst zu speichern. Somit sollten optionale Daten am besten nicht erfasst werden. Hierzu zählen z.B. Kreditkarten-Nummern, die nur der Bequemlichkeit halber gespeichert werden, damit der Benutzer sie nicht jedes Mal eingeben muss.

Die Aushandlung der Verschlüsselungsalgorithmen und -parameter sollte auf starke Algorithmen beschränkt sein und kein Downgrade auf unsichere Varianten erlauben. Hier ist es auch empfehlenswert, Perfect Forward Secrecy (PFS) und HTTP Strict Transport Security (HSTS) vom Kommunikationspartner zu fordern. Für HSTS wird ein neuer HTTP-Header namens Strict-Transport-Security erzeugt, der eine Zeitspanne (z.B. ein Jahr) angibt, innerhalb derer der Browser zu der Domain des antwortenden Servers ausschließlich verschlüsselte Verbindungen aufbauen darf. Ist keine Verschlüsselung möglich, muss er die Verbindung abbrechen.

Passwörter sollten mit Salt und effektiven Password-Hashfunktionen (z.B. PBKDF2) verarbeitet und gespeichert werden, um Offline-Angriffe zu erschweren. So wird verhindert, dass ein Angreifer, der in den Besitz der Passwort-Hashes gelangt, die Passwörter ermitteln kann.

24.6   A03 – Injection

Noch in der 2017er Version auf Platz 1 sind die Injection-Angriffe in Version 2021 auf Platz 3 gefallen. Sie gehören damit nach wie vor zu den gefährlichsten Angriffen. Wir werden uns dennoch in diesem Kapitel nur sehr kurz mit diesem Thema beschäftigen. Der Grund dafür ist ganz einfach: Injection-Angriffe sind so bedeutsam und vielfältig, dass wir sie im nächsten Kapitel ausführlich beschreiben werden. Daher werden wir uns an dieser Stelle auf eine kurze Übersicht beschränken, um uns nicht unnötig zu wiederholen.

24.6.1   Kategorien von Injection-Angriffen

Vielleicht haben Sie bisher im gesamten Buch einen Begriff vermisst: SQL-Injection‌. Tatsächlich handelt es sich um einen der wichtigsten Angriffsvektoren überhaupt. Andererseits ist die SQL-Injection, kurz: SQLi, nur eine Variante der Injection-Angriffe. Unter Injection-Angriffen verstehen wir unter anderem die folgenden Angriffstechniken:

• SQL Injection

• LDAP Injection

• XML Injection

• OS Command Injection

• Code Injection

• ORM Injection

• und so weiter

Die Liste lässt sich noch weiterführen, das obliegt aber dem nachfolgenden Kapitel. Injection-Angriffe sorgen dafür, dass Informationen und Daten in serverseitige Technologien derart injiziert werden, dass die Verarbeitung in der Webanwendung zu Ergebnissen führt, die dem Angreifer Zugang zu Systeminformationen, Datenbankinhalten oder zum System selbst ermöglichen.

24.6.2   Beispiel für einen Injection-Angriff

Die weitaus wichtigste Angriffsform ist die SQL-Injection. Dabei nutzt der Angreifer Schwachstellen in der Eingabevalidierung aus, um Ergebnisse zu erhalten, die der Programmierer nicht vorgesehen hat. Oftmals geht es darum, dass die Datenbank dazu gebracht wird, sensible Daten auszugeben. SQL-Injection ermöglicht jedoch auch noch weitere Angriffe, wie Sie im nächsten Kapitel sehen werden.

SQL‌ ist eine Datenbanksprache, mit deren Hilfe mit relationalen Datenbanken interagiert werden kann. Werden Benutzereingaben in einem Eingabefeld auf der Webseite gemacht, so leitet der Browser diese Informationen in einem POST-Request an den Server. Dahinter steckt nun in der Regel ein serverseitiges Programm oder Skript, das diese Benutzereingabe weiterverarbeitet und meistens in der einen oder anderen Form eine Datenbank-Interaktion durchführt, also entweder einen Datensatz erstellt, ändert oder aber Daten ausliest, um sie dem Benutzer zu präsentieren.

Für unser erstes Beispiel nutzen wir WebGoat aus didaktischen Gründen zunächst in einer älteren Version 8.0.0M24, da die entscheidende Seite zwischenzeitlich verändert wurde und das Beispiel in neueren Versionen nicht mehr verfügbar ist. Dies dient zunächst nur einer kurzen Demonstration zum Verständnis. Wenn Sie das nachfolgende Praxisbeispiel nachstellen möchten, können Sie auf der GitHub-Seite https://github.com/WebGoat/WebGoat unter Releases die passende Version auswählen, wie Abbildung 24.15 zeigt.

Abb. 24.15: Wählen Sie das passende Release von WebGoat aus.

Da es sich um eine Java-JAR-Datei handelt, die keiner Installation bedarf, können Sie beliebige WebGoat-Versionen bereitstellen und nach Bedarf aktivieren. Starten Sie also WebGoat, wie aus Kapitel 18 bekannt, mit folgendem Befehl, wobei Sie die IP-Adresse des Servers ggf. anpassen müssen, wenn Ihre Laborumgebung von unserer abweicht:

java -jar webgoat-server-8.0.0.M24.jar --server.address=192.168.1.213 

Nachdem Sie einen Benutzer angelegt haben, finden Sie in der WebGoat-Version 8.0.0M24 unter Punkt 7 im Injection Flaws|SQL Injection ein Eingabefeld, das Sie auffordert, Ihren Account-Namen einzugeben. Geben Sie Smith ein, wird Ihnen der Datensatz zweier existierender Benutzer namens Smith angezeigt, wie in Abbildung 24.16 dargestellt.

Abb. 24.16: Die reguläre Ausgabe der Anwendung

Lassen Sie sich nicht von der vermeintlichen Fehlermeldung irritieren. Das Ziel ist es hier schließlich, die Ausgabe zu manipulieren und nicht regulär zu nutzen. Hinter der Ausgabe steckt eine SQL-Abfrage der folgenden Art:

SELECT * FROM user_data WHERE last_name = 'userName' 

Es werden alle Daten (*) von allen Datensätzen aus der Tabelle user_data angefragt, bei denen im Feld last_name der Wert der Variablen userName enthalten ist. Diese werden dem Benutzer ausgegeben. Da es sich bei userName um einen String handelt, wird dieser in einfache Hochkommas eingefasst.

Der Angreifer möchte in diesem Szenario die Datensätze aller Benutzer anzeigen lassen. Da die SQL-Abfrage dynamisch gebildet wird, kann er folgenden Injection-String eingeben:

Smith' or 'a' = 'a 

Im Ergebnis wird dann folgendes SQL-Statement gebildet, wobei die durch uns manipulierten Bestandteile fett hervorgehoben sind:

SELECT * FROM user_data WHERE last_name = 'Smith' or 'a' = 'a' 

Damit ist die Bedingung nun nicht mehr, dass im Feld last_name die Zeichenkette Smith auftauchen muss. Stattdessen wird die Bedingung durch die Ergänzung or 'a' = 'a' immer wahr: a ist halt immer genau a, das wird sich nie ändern. Von daher könnte der Name Smith auch anders gewählt werden, er spielt keine Rolle mehr. Im Injection-String haben wir das erste und das letzte Hochkomma weggelassen, da dieses automatisch vom Programm bei der dynamischen Erstellung des SQL-Statements ergänzt wird. Das Ergebnis stellt sich dar, wie in Abbildung 24.17 gezeigt.

Abb. 24.17: Die SQL-Injection war erfolgreich.

Es werden alle Benutzerdatensätze angezeigt und in diesem Zusammenhang auch gleich die Kreditkarten-Nummern präsentiert. Happy Shopping!

Aufgabe: String-SQL-Injection

WebGoat stellt in neueren Versionen ab 8.0.0M25 (gilt bis mindestens Version 2023.4) eine ähnliche Aufgabe bereit. Allerdings werden hier Drop-down-Felder angezeigt, die der Anwender korrekt auswählen muss, um den entsprechenden SQL-String zusammenzustellen. Mit dem eben erlernten Wissen sollten Sie ohne Probleme in der Lage sein, diese Aufgabe zu lösen. Testen Sie sich selbst, die Aufgabe befindet sich im Menüpunkt (A3) Injection|SQL Injection (intro) unter Punkt 9.

In den nächsten beiden Kapiteln erfahren Sie noch wesentlich mehr über Injection-Angriffe im Allgemeinen sowie SQL-Injection im Speziellen, und wie Sie sich dagegen schützen können. Von daher gehen wir an dieser Stelle auch noch nicht auf die Schutzmaßnahmen ein. Eine spezielle Schwachstelle wollen wir dennoch an dieser Stelle noch betrachten.

24.6.3   Cross-Site-Scripting (XSS)

Eine der bekanntesten Schwachstellen im Web-Hacking ist das Cross-Site-Scripting‌, kurz: XSS‌ – nicht zu verwechseln mit CSS, einer HTML ergänzenden Technologie, die für Cascading Style Sheets steht. In den OWASP Top 10 2017 war XSS noch als eigener Punkt unter A07 geführt, in der Version 2017 ist XSS dann in A03 Injection aufgegangen. Auch wenn XSS-Angriffe durch diverse Schutzmaßnahmen auf den Webservern und in den Browsern an Bedeutung verloren haben, sind sie nach wie vor präsent, und jeder angehende Ethical Hacker und Penetration Tester sollte diesen Angriffsvektor gut verstanden haben. Nachfolgend schauen wir uns daher XSS einmal grundlegend an.

24.6.4   Wie funktioniert XSS?

XSS ist eine clientseitige Code-Injection-Technik, bei der der Browser dazu gebracht wird, unerwünschte Skripts auszuführen. In der Regel geht es darum, sensible Informationen an den Angreifer zu senden. XSS basiert auf JavaScript. »Cross-Site-Scripting« bedeutet, dass der Angreifer Code auf der Ziel-Website injiziert und das Opfer von einer anderen Site, also einem anderen Standort, unabhängig darauf zugreift. Der Browser des Opfers empfängt eine manipulierte Webseite mit entsprechendem JavaScript-Code, interpretiert diesen und sendet im Anschluss – aufgrund des Codes – vertrauliche Daten des Opfers (z.B. ein Session-Cookie) an den Webserver des Angreifers, der unter einer beliebigen anderen Domain erreichbar ist. Abbildung 24.18 verdeutlicht das Prinzip.

Es gibt diverse Varianten von XSS-Angriffen, die wir Ihnen gleich noch genauer vorstellen werden. Ziele eines XSS-Angriffs sind unter anderem:

• Session Hijacking (Browser übermittelt Session-Cookies)

• Übernahme des Benutzerbrowsers

• Phishing-Angriffe

• Website-Defacements

Sendet der Angreifer dem Opfer einen Link zu der manipulierten Webseite, so kann er diesen z.B. in Kurz-URLs tarnen. Über einen Shortener-Dienst wie z.B. bit.ly wird aus http://www.hacking-akademie.de/ kurz https://bit.ly/2kes72B.

Abb. 24.18: Ein typischer (Stored) XSS-Angriff

24.6.5   Ein einfaches XSS-Beispiel

Damit der nachfolgende Test funktioniert, muss nslookup auf dem Webserver installiert sein. Dies ist bei neueren Debian-Versionen nicht mehr standardmäßig der Fall. Sie können das Tool ggf. mit folgendem Befehl nachinstallieren:

apt install dnsutils 

Geben Sie nslookup im CLI ein, um das Tool zu testen. Wenn es installiert ist, dann startet es entsprechend. Anschließend sind wir startbereit. Erneut arbeiten wir mit Mutillidae. Gehen Sie im Menü auf DNS Lookup unter A7 – Cross Site Scripting (XSS) wie in Abbildung 24.19 gezeigt.

Abb. 24.19: Ein einfaches XSS-Beispiel auf der Seite DNSLookup

Hier werden Sie aufgefordert, einen Hostnamen bzw. eine IP-Adresse einzugeben. Das ist schon einmal sehr wichtig, da die Variable, in der der Wert gespeichert wird, vermutlich nicht vom Typ Numeric oder ähnlich ist, sondern Zeichenketten erlaubt. Geben Sie test ein und klicken Sie auf Lookup DNS. Der Browser sendet die Angabe per POST-Request zum Server. Im Ergebnis erhalten Sie die Rückmeldung, dass der Name nicht aufgelöst werden konnte (siehe Abbildung 24.20).

Abb. 24.20: Die Eingabe test konnte nicht aufgelöst werden.

Interessant hierbei ist, dass das serverseitige Skript in der Antwort die Eingabe des Benutzers erneut angibt, also reflektiert. Das können wir uns zunutze machen. Geben Sie in das Eingabefeld Folgendes ein:

<script>alert("XSS erfolgreich")</script> 

Klicken Sie nun erneut auf Lookup DNS, so erscheint ein Popup mit einer entsprechenden Meldung wie in Abbildung 24.21 dargestellt.

Abb. 24.21: Ein erster erfolgreicher XSS-Angriff

Der Hintergrund hierzu ist, dass der JavaScript-Code hinter Results for vom serverseitigen Script eingefügt und die Ergebnisseite so an den Browser zurückgesendet wird. Für den Browser ist das jetzt aktiver Code, den er ausführen muss, und daher wird über die Funktion alert() ein Popup-Fenster mit entsprechendem Text angezeigt.

Normalerweise wird der Zugriff auf Objekte im Browser oder Browsercache nur gestattet, wenn diese Objekte von der eigenen Webseite stammen. Dies wird als Same Origin Policy (SOP) bezeichnet und schränkt Skriptsprachen wie JavaScript auf die eigene Domain ein. Damit wird verhindert, dass ein Angreifer über JavaScript-Code z.B. ein fremdes Session-Cookie auslesen kann.

Wird Code via XSS eingeschleust, scheint dieser von der aktuellen Webseite zu kommen und verletzt daher nicht die SOP. Damit wird ggf. auch das Auslesen des Session-Cookies möglich. Dies geschieht z.B. durch folgenden Code:

<SCRIPT>alert("Cookie"+document.cookie)</SCRIPT> 

Im Ergebnis stellt sich das Popup-Fenster dann dar wie in Abbildung 24.22 gezeigt.

Abb. 24.22: Das Session-Cookie wird angezeigt.

Dementsprechend ist es für den Angreifer nur ein weiterer Schritt, diese Daten im Rahmen seines bösartigen XSS-Codes an einen Server zu senden, der unter seiner Kontrolle steht.

24.6.6   XSS-Varianten

Es gibt hauptsächlich drei Varianten von Cross-Site-Scripting.

Reflektiertes XSS (engl. reflective, non-persistent XSS)

Diese Form haben Sie eben bereits kennengelernt. In diesem Fall wird die Benutzereingabe direkt vom Server zurückgesendet (reflektiert). Nicht-persistent bzw. non-persistent besagt, dass der Code nur temporär eingeschleust, jedoch nicht gespeichert wird. Zu einem späteren Zeitpunkt ist der Schadcode nicht mehr enthalten. In vielen Fällen kann der Code über Variablen im Rahmen eines GET-Requests, aber auch in der URL mitgeliefert werden, sodass der Angreifer dem Opfer den manipulierten Link über einen Shortlink (z.B. zu erstellen bei https://bitly.com/) versteckt unterschieben kann. Dies wird dann z.B. über E-Mail oder Chat in der folgenden Art übermittelt: »Hey, schau dir mal dieses lustige YouTube-Video an!« Dahinter steckt dann z.B. eine URL wie die folgende: http://www.example.com/page.php?user=<script>alert("XSS")</script>.

Stored/Persistent XSS

In dieser Variante wird der XSS-Code in einer Datenbank gespeichert und kann jederzeit wieder aufgerufen werden. Ein einfaches Beispiel hierfür ist ein manipulierter Gästebuch-Eintrag, der XSS-Code enthält. Der Eintrag wird vom verwundbaren Server nicht korrekt gefiltert und somit landet JavaScript-Code in dem Datensatz der Datenbank, in dem der Gästebuch-Eintrag gespeichert wird. Ruft ein anderer Benutzer das Gästebuch zu einem späteren Zeitpunkt auf, werden der manipulierte Datensatz geladen (da ja jeder die Einträge der anderen Gäste sehen darf) und der XSS-Code ausgeführt. Gleich im nächsten Abschnitt lernen Sie noch ein praktisches Beispiel für Stored XSS kennen.

DOM-basiertes XSS (Dom based XSS)

Sie erinnern sich: DOM steht für Direct Object Model und stellt als Spezifikation die Grundlage für die hierarchische Struktur von HTML- und XML-Dokumenten bereit. DOM definiert die HTML-Elemente (z.B. <ul></ul> für unordered list) als hierarchische Objekte, und in diesem Zusammenhang deren Methoden und Attribute sowie die Events dieser Objekte. Damit ist DOM eine Schnittstelle (API), über die auf HTML-Objekte zugegriffen bzw. diese manipuliert werden können. Dies geschieht in der Regel durch JavaScript. Bei DOM-basiertem XSS (DOM based XSS) ist kein Server beteiligt. Stattdessen wird der Code direkt in die Webseite im Browser injiziert.

Die Stelle, an der der bösartige Code übernommen wird, bezeichnen wir als Source, die Stelle, an der der Code ausgeführt wird, als Sink. Betrachten wir folgendes HTML-Beispiel, das der Abhandlung von Amit Klein (2005) über DOM based XSS entlehnt ist:

<HTML>
<TITLE>Welcome!</TITLE>
Hi
<SCRIPT>
var pos=document.URL.indexOf("name=")+5;
document.write(document.URL.substring(pos,document.URL.length));
</SCRIPT>
<BR>
Welcome to our system
...
</HTML> 

In dieser verwundbaren Website wird in Zeile 5 über die Methode document.URL.indexOF() der im GET-Request übergebene Name des Benutzers ausgelesen (das ist die Source), in Zeile 6 wird eben dieser Name über die Methode document.write() ausgegeben (das ist der Sink). Ein nettes Ansinnen, bis jemand eine URL wie die folgende verwendet:

http://www.vulnerable.site/welcome.html?name=%3cscript%3ealert(document.cookie)%3c/script> 

In diesem Fall wird der Name durch ein Skript ersetzt, das anschließend ausgeführt wird. Wie in http://www.webappsec.org/projects/articles/071105.shtml zu lesen ist, funktioniert das nur unter bestimmten Voraussetzungen. DOM based XSS hat nicht dieselbe Bedeutung wie die anderen beiden Varianten, aber Sie sollten das Prinzip trotzdem verstanden haben.

24.6.7   Ein Beispiel für Stored XSS

In diesem Szenario nutzen wir DVWA. Falls Sie DVWA noch nicht heruntergeladen und installiert haben, können Sie Metasploitable starten,über http://192.168.1.206 auf die Homepage Ihres Metasploitable-Systems gehen (IP-Adresse ggf. anpassen) und dort DVWA auswählen, um zu der Anwendung zu gelangen. Nach einer Anmeldung mit admin/password stellen Sie über den Menüpunkt Setup sicher, dass die Datenbank über Create / Reset Database zurückgesetzt wurde (siehe Abbildung 24.23).

Abb. 24.23: Wir setzen die Datenbank auf den Ausgangszustand zurück.

Im nächsten Schritt stellen Sie zudem sicher, dass das Security-Level auf low steht. Dazu wechseln Sie in den Menüpunkt DVWA Security und stellen dort low ein. Durch die Auswahl des Security-Levels können Sie den Schwierigkeitsgrad später erhöhen.

Jetzt können wir starten. Gehen Sie auf den Menüpunkt XSS stored. Dort sehen Sie ein Gästebuch mit einem Namensfeld inklusive Eingabefeld für Ihre Nachricht. Testweise können Sie zunächst eine normale Nachricht hinterlassen, wie in Abbildung 24.24 gezeigt.

Abb. 24.24: Eine normale Nachricht

Diese Nachricht ist nun in der Datenbank gespeichert und wird – zusätzlich zur Test-Nachricht, die vorher schon vorhanden war – angezeigt. Öffnen Sie die Seite mit einem anderen Browser (auch von einem anderen System möglich), sehen Sie dieselben beiden Nachrichten. Testen Sie dies aus, bevor Sie fortfahren. Denken Sie bitte daran, nun auch im zweiten Browser das Security-Level auf low zu stellen.

Geben Sie nun einen Namen Ihrer Wahl im Feld Name, und im Feld Message die folgende Zeile ein:

<SCRIPT>alert("Cookie"+document.cookie)</SCRIPT> 

Es erscheint ein Popup, wie Sie es bereits kennen (siehe Abbildung 24.22). Das Spannende ist, dass im zweiten Browser ebenfalls ein Session-Cookie angezeigt wird, wenn Sie die Seite neu laden – und zwar ein anderes, wie Sie feststellen werden, da es sich um eine andere Session handelt (siehe Abbildung 24.25). Der gespeicherte Inhalt der Kommentare bzw. der Nachrichten wird von jedem JavaScript-aktivierten Browser als Code interpretiert und ausgeführt.

Abb. 24.25: Auch der zweite Browser zeigt ein Session-Cookie an.

Dieses Beispiel zeigt, wie gefährlich Stored XSS ist, da das Opfer im Gegensatz zu Reflected XSS nicht explizit dazu gebracht werden muss, den manipulierten Link anzuklicken. Stattdessen muss der Angreifer nur eine Webseite identifizieren, die zum einen verwundbar ist und zum anderen vom Opfer regelmäßig besucht wird.

24.6.8   Exkurs: Cross-Site-Request-Forgery (CSRF)

Eine Angriffsform, die häufig im Zusammenhang mit XSS genannt wird, ist CSRF – Cross-Site-Request-Forgery‌. Sie hatte bis 2013 sogar mit A8 einen eigenen Platz in den OWASP Top 10. Mittlerweile ist diese Angriffsform durch verbesserte Sicherheitsmechanismen in der Session-Verwaltung nicht mehr so häufig anzutreffen.

CSRF (auch: ‌XSRF) basiert darauf, eine authentifizierte Session eines Benutzers auszunutzen, um über eine fremde Webseite unter der Kontrolle des Angreifers (Cross Site) einen HTTP-Request zu provozieren (Request Forgery), der nur im Rahmen einer authentifizierten Session funktioniert.

Wie kann das funktionieren? Das Prinzip ist folgendes:

1. Alice loggt sich in der Webanwendung von Bob ein und ist damit authentifiziert. Der Browser sendet ab sofort bei jedem Request sein Authentication-Cookie mit – das passiert vollkommen automatisch.

2. Mallory schiebt Alice einen manipulierten Link unter. Der Link enthält z.B. einen versteckten (!) Request zum Ändern des Passworts für die authentifizierte Session zu Bobs Webanwendung.

3. Alice klickt auf den Link in einem anderen Browser-Tab. Da die Authentifizierung bei einer Webanwendung nicht Tab-gebunden, sondern Browser-weit gilt, wird auch hier das Authentication-Cookie automatisch vom Browser mitgesendet.

4. Das Passwort wird geändert, ohne dass Alice etwas davon mitbekommt. Mallory ist nun in der Lage, sich an der Webanwendung als Alice anzumelden (sofern er den Usernamen kennt).

Abbildung 24.26 macht den Vorgang deutlich.

Abb. 24.26: Cross-Site-Request-Forgery (CSRF)

Der Angreifer nutzt also eine etablierte, authentifizierte Session des Opfers aus, um einen manipulierten Request in diese Session zu injizieren. Die Webanwendung führt den Request aus, da es sich aus ihrer Sicht um eine reguläre Anfrage des authentifizierten Opfers handelt. Das Opfer selbst bekommt in der Regel davon nichts mit.

Die Herausforderung für den Angreifer besteht in erster Linie darin, dafür zu sorgen, dass das Opfer den manipulierten externen Request ausführt. Dazu kann z.B. XSS zum Einsatz kommen, da es hier möglich ist, über die Webanwendung einen manipulierten Link zu platzieren, der beispielsweise zu einer Webseite führt, die in einem Formular einen versteckten Request zum Auslesen des Cookies oder zum Ändern des Passworts enthält.

Alternativ kann Mallory Alice auch durch Social-Engineering-Methoden dazu verleiten, auf den Link zu klicken. Wichtig ist, dass bei Alice zu diesem Zeitpunkt eine authentifizierte Session zur betreffenden Webanwendung besteht.

Auf den Punkt gebracht: CSRF basiert darauf, dass der Webserver dem Browser vertraut, von dem er einen Request erhält. Bei XSS ist es der Browser bzw. der User, der einer Webanwendung vertraut, mit der er kommuniziert. CSRF und XSS sind grundsätzlich verschiedene Angriffe. Allerdings kann XSS effektiv dazu eingesetzt werden, um einen CSRF-Angriff durchzuführen.

CSRF ist zum einen eine Form des Injection-Angriffs (siehe nachfolgende Kapitel) als auch zum anderen ein Session-Hijacking-Angriff. Hier zeigt sich, dass die Klassifizierung von Hacking-Angriffen nicht immer linear und eindeutig ist.

24.6.9   Schutzmaßnahmen gegen XSS-Angriffe

Die in diesem Rahmen gezeigten Beispiele sind sehr einfach gehalten und sollen Ihnen nur das Prinzip und das Konzept von XSS verdeutlichen. Dennoch sollte klar geworden sein, dass XSS nach wie vor eine große Gefahr darstellt, auch wenn mittlerweile diverse Sicherheitsmechanismen in den Browsern eingebaut wurden.

Die Abwehr gegen XSS umfasst jedoch nicht nur die Browser, sondern insbesondere auch die serverseitigen Webtechnologien. Das OWASP Cheat Sheet 'XSS Prevention' ist erhältlich unter https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.md und enthält diverse Regeln und Tipps zur Vermeidung von XSS-Schwachstellen. Diese Seite sollten Sie sich unbedingt durchlesen.

Falls Ihnen der Link zu komplex ist, gehen Sie auf https://cheatsheetseries.owasp.org/ und suchen Sie dort das gewünschte Dokument. OWASP stellt hier und auf GitHub diverse CheatSheets bereit.

Die wichtigste Regel ist, dass nicht vertrauenswürdige Inhalte von aktiven Browserinhalten getrennt werden müssen. Das kann z.B. durch die Verwendung von Frameworks geschehen, die XSS-Code automatisch eliminieren bzw. maskieren. Dazu gehören React JS oder auch das aktuelle Ruby on Rails.

Die Eingabevalidierung ist der wichtigste Schutz vor Reflective und Stored XSS. Hierzu gibt das oben angegebene Dokument zahlreiche Tipps und Hinweise, wie gefährliche Zeichen oder aktive Inhalte maskiert bzw. aussortiert werden können. Ein Zeichen zu maskieren bedeutet, dass es seiner Funktion beraubt wird. Bei Linux wird hier ein Backslash (\) vor das Zeichen gesetzt (z.B. vor ein Leerzeichen), um das Zeichen anzeigen zu können, ohne dass der Interpreter es auswertet. Die Maskierung von Zeichen wird im Englischen auch als »to escape a string« bezeichnet. In diesem Zusammenhang wird auch von Sanitizer‌-Funktionen gesprochen, die die Eingabe validieren und filtern. »Sanitizer« bedeutet wörtlich übersetzt »Desinfektionsmittel«.

Auch für DOM based XSS gibt es bei OWASP Hilfe. Sie finden unter https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/DOM_based_XSS_Prevention_Cheat_Sheet.md ein Dokument, das Ihnen Tipps und Tricks an die Hand gibt, um sich gegen diese Variante von XSS zu schützen. Da dies an dieser Stelle bereits weit in die Thematik »Entwicklung sicherer Webanwendungen« geht und wir zur Verdeutlichung diverse Code-Beispiele bringen müssten, belassen wir es beim Hinweis auf das o.a. Dokument.

Gegen CSRF hilft serverseitig ein spezielles Token, das als Geheimnis zwischen Browser und Webanwendung für jede Transaktion zusätzlich zum Authentication-Cookie eingesetzt wird. Dies wird auch als CSRF-Token bezeichnet.

Auf der Clientseite sollte der User sicherstellen, dass sein System keine Schadsoftware enthält. Auch Malware kann dazu genutzt werden, CSRF-Angriffe über verschiedene Mechanismen durchzuführen oder zu unterstützen.

24.7   A04 – Insecure Design

Dieser Punkt ist in den OWASP Top 10 neu hinzugekommen und tatsächlich trifft dieser Punkt den Kern diverser Schwachstellen in Webanwendungen – wenn auch nicht aller, wie wir nachfolgend ausführen werden.

24.7.1   Was bedeutet unsicheres Design?

Ist eine Anwendung anfällig für Hacking-Angriffe, kann das grundsätzlich an zwei Dingen liegen:

1. Die Anwendung ist unsicher programmiert, es liegen Fehler im Design vor.

2. Die Anwendung verfügt über ein sicheres Design, aber sie wurde unsicher und fehlerhaft implementiert.

Im zweiten Fall stellen die Entwickler der Anwendung dem Administrator durchaus die Werkzeuge und Optionen bereit, um die Anwendung nach allen Seiten abzusichern, aber der Administrator nutzt diese Möglichkeiten nicht oder nur unzureichend. Im ersten Fall jedoch haben wir ein grundsätzliches Problem: Fehler im Design können nicht durch eine perfekte Implementierung behoben werden, da die Anwendung keine Sicherheitskontrollen zur Abwehr bestimmter Angriffe bereitstellt.

Ein ganz typisches Beispiel ist die fehlende Sanitizing-Funktion für Eingaben in Webanwendungen, wie wir das im vorigen Punkt bei der SQL Injection schon gesehen haben. Der Administrator hat nur sehr eingeschränkte Möglichkeiten, sich und seine Umgebung dagegen zu schützen. Ein Schutz kann dann nur darin bestehen, die Anwendung vor Angriffen extern abzuschirmen, z.B. durch den Einsatz von Web Application Firewalls (WAF), die als Reverse Proxy davorgeschaltet werden. Das kann aber nicht der Sinn der Sache sein, auch wenn WAFs generell eine empfehlenswerte Zusatzmaßnahme zur Absicherung von Webanwendungen darstellen.

Hier noch ein weiteres Beispiel aus der OWASP-Top 10-Seite. Vermutlich kennen Sie es selbst: Wir alle vergessen hin und wieder unsere Anmeldeinformationen für eine bestimmte Webanwendung. Ein möglicher, häufiger anzutreffender Workflow zur Wiederherstellung von Anmeldeinformationen kann Fragen und Antworten enthalten. Sie klicken auf Reset Password oder so ähnlich und erhalten drei Fragen, die Sie zuvor bei der Anmeldung mit einer klar definierten Antwort versehen haben und nun in exakt gleicher Art beantworten müssen, z.B:

• Wie lautet der Mädchenname Ihrer Mutter?

• Wie hieß Ihr erstes Haustier

• In welcher Stadt sind Sie geboren

• usw.

Nun ist es allerdings so, dass derartige Identitätsnachweise relativ einfach zu knacken sind, da mehrere Personen diese Informationen kennen könnten. Diverse Sicherheitsstandards (NIST 800-63b, OWASP ASVS und OWASP Top 10) sprechen sich strikt dagegen aus und fordern, dass ein solcher Code entfernt und durch sicheren Code ersetzt wird.

Zur Vermeidung eines unsicheren Designs muss bei der Entwicklung einer Anwendung viel grundsätzlicher angesetzt werden, als die Verantwortung lediglich auf den implementierenden Administrator abzuschieben. Einer der Faktoren, die zu einem unsicheren Design beitragen, ist das Fehlen von Risikoprofilen und Geschäftsanforderungen, einschließlich der Schutzanforderungen hinsichtlich Vertraulichkeit, Verfügbarkeit und Authentizität (also der CIA-Triade).

24.7.2   Sichere Webentwicklung

Für ein Design von sicheren Anwendungen ist also eine grundsätzliche Herangehensweise erforderlich, die bereits in der Planungsphase beginnt. Um robusten Code zu erstellen, ist eine Bedrohungsmodellierung erforderlich, wobei die Bedrohungen kontinuierlich bewertet werden müssen, um bekannte Angriffsmethoden zu verhindern. Dies ist ein Prozess, der ständig laufen muss. Bei der Entwicklung der User Story (also der regulären Bewegungen des Anwenders innerhalb der Webanwendung) sollten die korrekten Ablauf- und Fehlerzustände analysiert und berücksichtigt werden. In diesem Zusammenhang müssen die Zugriffs- und Sicherheitskontrollen genau analysiert und bestimmt werden. Das erfordert das Abfangen aller möglichen Fehlerzustände und eine genaue Definition der Abläufe.

Wichtig ist, dass dies alle Beteiligten, insbesondere die verantwortlichen Entwickler, gut verstanden haben und alle Punkte klar besprochen und vereinbart werden. In der Regel führen unklare Kommunikation und nicht zuletzt Zeitdruck immer wieder zu Fehlern in der Anwendung. Für die Entwicklung sicherer Anwendungen ist eine umfassende Methodik und Vorgehensweise notwendig. Das erfordert einen sicheren Entwicklungslebenszyklus, eine regelmäßige und aktualisierte Bedrohungsmodellierung und fähige Entwickler, die über eine hohe Sensibilisierung für die Security-Problematik verfügen.

24.7.3   Schutzmaßnahmen

OWASP Top 10 empfiehlt eine Reihe von Sicherheitsmaßnahmen zur Vorbeugung von Designfehlern in Webanwendungen. Dazu zählen unter anderem:

• Ziehen Sie Security-Experten zurate und richten Sie mit deren Hilfe einen sicheren Entwicklungslebenszyklus ein, um die Gestaltung von Sicherheits- und Datenschutzkontrollen zu optimieren.

• Erstellen Sie eine Bibliothek mit sicheren Entwurfsmustern bzw. gebrauchsfertigen Komponenten, um Routineaufgaben sicher zu gestalten.

• Zur Gestaltung sicherer Authentifizierungsprozesse und einer zuverlässigen Zugriffskontrolle nutzen Sie die Bedrohungsmodellierung.

• Integrieren Sie Plausibilitätsprüfungen auf jeder Ebene der Anwendung.

• Führen Sie im Entwicklungsprozess immer wieder Tests und Code-Reviews durch, um sicherzustellen, dass alle kritischen Datenflüsse gegen das Bedrohungsmodell resistent sind.

• Trennen Sie die einzelnen Komponenten und Ebenen der Anwendung je nach Gefährdung und Schutzbedarf ab. Das umfasst die Anwendungs- aber auch die Netzwerkebene.

Es gibt noch viele weitere Schutzmechanismen und tatsächlich existieren ganze Bücher zum Thema »sichere Webanwendung«, aber an dieser Stelle geht es in erster Linie um ein Grundverständnis für die Problematik des unsicheren Designs, eine der wichtigsten Schwachstellen in Webanwendungen.

24.8   A05 – Security Misconfiguration

Weiter geht es mit einer sehr allgemeinen Schwachstelle. Im Gegensatz zu A05 geht es bei A05 – Security Misconfiguration weniger um konzeptionelle Fragen und Design-Schwächen, sondern um die ganz konkrete, sicherheitsbezogene Konfiguration einer Anwendung bzw. Anwendungskomponente. Hier haben die Entwickler dem Administrator also die Möglichkeiten zur Absicherung einer Anwendung an die Hand gegeben, die dieser aber nicht oder nur unzureichend nutzt.

24.8.1   Typische Fehlkonfigurationen

Zunächst einmal sollten wir uns im Klaren darüber sein, dass Fehlkonfigurationen auf allen Ebenen vorkommen können: Netzwerkdienste, Betriebssystem-Plattform, Web-, Anwendungs- und Datenbankserver, in den Frameworks, in selbst geschriebenem Code und so weiter. Das macht es für die Verantwortlichen einer Webanwendung auch so schwierig, alle sicherheitsrelevanten Aspekte zu beachten. Schauen wir auf gängige Fehlkonfigurationen:

• In vielen Fällen werden Komponenten nicht ausreichend gehärtet bzw. in der (unsicheren) Default-Konfiguration belassen.

• Dies betrifft insbesondere auch ungenutzte Komponenten und Dienste, die sich an Ports binden, aber gar nicht benötigt werden. Jede aktive Komponente und jeder Dienst, der von außen ansprechbar ist, stellt eine mögliche Schwachstelle dar.

• Default-Accounts bleiben aktiviert – im Internet existieren umfangreiche Listen mit den Standard-Zugangsdaten für diverse Systeme, Komponenten und Serverdienste.

• Fehler werden umfassend zurückgemeldet – nicht nur, dass dadurch evtl. auch Injection-Angriffe möglich werden, sondern oftmals liefert der antwortende Serverdienst auch seinen Namen sowie die Version zurück. Der Angreifer bedankt sich und erspart sich das Banner Grabbing.

• Security-Features bleiben deaktiviert: Aus Unwissenheit oder aufgrund fehlerhafter Konfigurationsprozesse werden vorhandene und empfohlene Features nicht aktiviert oder nicht korrekt konfiguriert. Dies betrifft auch Features, die durch ein Update der Software unbemerkt Einzug gehalten haben.

• Es werden unsichere Einstellungen für Webserver, Webanwendungen oder Frameworks vorgenommen. Das betrifft z.B. schwache Verschlüsselungsalgorithmen bzw. Downgrade-Möglichkeiten.

• Security-Header werden nicht eingesetzt: Wie bereits angedeutet, existieren diverse optionale Security-Header als Sicherheitsfunktionen, die im HTTP gesetzt werden können. Hierzu zählen unter anderem HSTS, X-Frame-Options, X-XSS-Protection und diverse mehr.

• Es werden verwundbare Komponenten eingesetzt – durch den Einsatz veralteter oder bekanntermaßen unsicherer und angreifbarer Komponenten wird die Anwendung Risiken und Gefahren ausgesetzt, die sich ein Angreifer zunutze machen kann.

Die Liste möglicher Fehlkonfigurationen ist damit keineswegs abgeschlossen, jedoch sollten Sie nun einen guten Eindruck davon gewonnen haben, auf was sich diese Schwachstelle bezieht.

24.8.2   Directory Browsing

Es gehört zu den wichtigsten Sicherheitsmaßnahmen, das Verzeichnislisting des DocumentRoot-Verzeichnisses einer Webpräsenz zu deaktivieren, da sich ein Angreifer ansonsten in aller Ruhe umschauen und jedes Verzeichnis und jede Datei direkt aufrufen kann. Was aber nicht selten vergessen wird, sind die Unterverzeichnisse. Werden diese direkt aufgerufen, zeigen sie ihren Inhalt an, wenn dies nicht unterbunden wird.

Schauen wir uns ein Beispiel in Mutillidae an. Rufen Sie das DocumentRoot-Verzeichnis von einem anderen System durch Eingabe von http://192.168.1.213/mutillidae im Browser auf, so werden Sie auf die Startdatei index.php umgeleitet. So ist es richtig. Ein Blick auf die Links hinter den Inhalten im Menüpunkt Documentation zeigt, dass es ein Unterverzeichnis documentation gibt, wie in Abbildung 24.27 verdeutlicht. Dies zeigt die Statusleiste des Browsers, wenn der Mauszeiger auf dem entsprechenden Menüpunkt steht.

Abb. 24.27: Die Links im Menü verfolgen

Geben Sie das Verzeichnis im Browser ein, zeigt Ihnen der Webserver aufgrund fehlender Sicherheitsmaßnahmen den Inhalt dieses Verzeichnisses, wie in Abbildung 24.28 dargestellt.

Abb. 24.28: Der Inhalt des Verzeichnisses /mutillidae/documentation

Hier können Inhalte zum Vorschein kommen, die nicht für die Öffentlichkeit bestimmt sind. Werfen Sie z.B. einen Blick auf Mutillidae-Test-Scripts.txt. Hier finden Sie mehr oder minder die Anleitung für die Exploits aller Schwachstellen in Mutillidae! Dies ist übrigens eines der Easter Eggs in Mutillidae. Stellen Sie sich vor, dass es sich um den Report eines internen Penetration-Tests handelt, der temporär oder versehentlich in diesem Verzeichnis abgelegt wurde und anschließend in falsche Hände gelangt ...

Im Übrigen ist das der Grund, der Tools wie DirBuster so gefährlich macht. DirBuster findet durch Brute-Force- bzw. Dictionary-Angriffe alle gängigen Unterverzeichnisse und listet ggf. deren Inhalte auf.

Abb. 24.29: DirBuster entdeckt sie alle ...

Auch hier hätten wir das Mutillidae-Test-Script gefunden, wie Abbildung 24.29 zeigt.

24.8.3   Allgemeine Schutzmaßnahmen

Zunächst einmal gilt es, den Webserver und seine Komponenten zu härten. Dazu sollten alle nicht genutzten Dienste und Ports deaktiviert werden. Das Ziel ist es, ein Minimalsystem bereitzustellen, das so viel Features wie nötig, aber so wenig Angriffsfläche wie möglich bereitstellt.

Die Konfiguration aller beteiligten Komponenten, angefangen von den Netzwerkgeräten über die Betriebssystemplattform, den Webservern bis hin zu den Webanwendungen und eingesetzten Frameworks, muss jeweils einzeln betrachtet und nach Best Practice und auf das eigene Szenario angepasst vorgenommen werden. Hierbei helfen Standards. Zum einen sollten gleichartige Komponenten möglichst einheitlich konfiguriert werden und zum anderen helfen automatisierte Hardening-Prozesse dabei, menschliche Fehler zu vermeiden. Diese Arbeit kann z.B. durch Konfigurationstemplates oder über diverse, frei verfügbare Hardening-Programme erfolgen. Hier existieren für fast jede Plattform und Anwendung passende Tools.

Es sollten weiterhin Sicherheitsrichtlinien entwickelt werden, die den Einsatz von gängigen Sicherheitsfeatures fordern. Dazu gehört auch der Einsatz von Security-Headern, wie z.B. HSTS, HPKP und X-Frame-Option.

24.8.4   A4 – XML External Entities (XXE)

In den OWASP Top 10 2017 noch als eigene Schwachstelle unter A04 aufgeführt sind die XML External Entities (XXE) nun in den Punkt A05 Security Misconfiguration eingegangen. Falls Sie sich noch nicht mit XML und ähnlichen Webtechnologien auskennen, werden Sie sich mit dem Verständnis dieser Schwachstelle unter Umständen etwas schwerer tun. Sie ist aber in der Praxis so bedeutend, dass wir diesen Punkt auf jeden Fall grundlegend besprechen müssen. Mit XXE‌ ist es möglich, bestimmte externe Datenquellen in XML-Dateien zu integrieren, die bei der Verarbeitung der XML-Daten zu einer Ausgabe dieser externen Informationen führen. Um dies greifbarer zu machen, schauen wir uns in diesem Abschnitt auch gleich ein praktisches Beispiel an.

24.8.5   XML-Entities

Eine XML-Entity‌ (zu Deutsch: Entität) ist ein definiertes Kürzel in XML. Es werden ein Name für die Entity und deren Inhalt festgelegt, auf den über den Namen der Entity referenziert werden kann. Das funktioniert z.B. ähnlich wie ein Makro bei Microsoft Word.

Dieser Vorgang wird über die Document Type Definition (DTD) definiert, die die Regeln für eine XML-Sprache festlegt. Die folgenden Informationen sind aus Platzgründen vereinfacht und sollen nur das generelle Vorgehen verdeutlichen. Eine Entity wird nach der DTD wie folgt festgelegt:

<!ENTITY Name [SYSTEM|PUBLIC] "Wert" [zusätzliche Angaben] > 

Jede Entity erhält also einen Namen, ggf. optionale Parameter und dann einen Wert, auf den referenziert werden kann. Hier ein einfaches Beispiel aus https://wiki.selfhtml.org/:

<!ENTITY mfg "mit freundlichen Gr&#252;&#223;en"> 

Der Wert wird UTF-8-codiert, um dem Webstandard zu entsprechen. Jedes Mal, wenn im XML-Dokument nun mit &mfg auf den Wert dieser Entity referenziert wird, dann wird mit freundlichen Grüßen ausgegeben. Das nachfolgende Beispiel (aus derselben Quelle) verdeutlicht die Anwendung:

<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE text-mit-baustein SYSTEM "text-mit-baustein.dtd">
<text-mit-baustein>
ich verbleibe &mfg;
</text-mit-baustein> 

XML-Entities sind also per se nichts Schlechtes. Nun bietet DTD die Möglichkeit, auch externe Entities (External Entities) zu definieren. Das sind externe Datenquellen, wobei »extern« alles außerhalb der betreffenden XML-Datei umfasst. Wird z.B. auf eine lokal gespeicherte Datei verwiesen, so wird das Schlüsselwort SYSTEM davorgesetzt. Damit können Inhalte von externen Dateien eingebunden werden, um z.B. eine bessere Struktur in die XML-basierende Anwendung zu bringen.

Aber genau hier liegt dann auch das Problem: Kann ein Angreifer ein XML-Dokument z.B. so manipulieren, dass der Inhalt vertraulicher Dateien angezeigt wird, dann liegt eine Sicherheitslücke vor. Läuft der Parser mit entsprechenden Rechten, kann sich der Angreifer diverse teilweise systemkritische Dateien anzeigen lassen. Schauen wir uns das einmal an.

24.8.6   Ein Beispiel für einen XXE-Angriff

Wir nutzen für eine Demonstration erneut Mutillidae. Abbildung 24.30 können Sie erkennen, wie Sie über die Menüstruktur zum XML Validator gelangen. Dort haben wir einen harmlosen XML-Code eingetragen und durch den XML-Parser verarbeiten lassen. Im Ergebnis kommt der Text Hello World heraus.

Abb. 24.30: Der XML-Validator in Aktion

Der nun folgende (einzeilige!) XML-Code erstellt eine External Entity namens xxetest, deren Wert die Datei /etc/passwd ist. Über den anschließenden Aufruf von &xxetest fordern wir den XML-Parser auf, den Inhalt dieser Datei auszugeben.

<!DOCTYPE test [<!ENTITY xxetest SYSTEM "file:///etc/passwd">]><test>&xxetest;</test> 

Schauen wir, was passiert, wenn wir diesen Code auf der Validator-Seite eingeben. Abbildung 24.31 zeigt das Ergebnis.

Tatsächlich gibt der XML-Parser den Inhalt der Datei /etc/passwd aus und zeigt damit in aller Deutlichkeit, wie problematisch diese Schwachstelle ist. Nun ist in der Realität selten ein komfortables Feld vorhanden, in das XML-Code eingegeben werden kann. Stattdessen sind es z.B. APIs, die über XML Daten erhalten, die der Angreifer in der gezeigten Art manipulieren kann.

Im Übrigen sind durch XXE-Schwachstellen nicht nur vertrauliche Daten abrufbar, sondern auch andere Angriffstypen wie z.B. Cross-Site-Scripting (XSS) und ähnliche Formen möglich. Hier wird deutlich, dass einige Schwachstellen wiederum andere Angriffsvektoren ermöglichen.

Abb. 24.31: Ein XXE-Angriff auf die Benutzerdatenbank des Systems

Genau genommen haben wir Ihnen im obigen Beispiel auch ein Anwendungsszenario für A3 – Verlust der Vertraulichkeit sensibler Daten gezeigt. Es greift alles ineinander.

24.8.7   Schutzmaßnahmen

Eine Abfrage wie die oben gezeigte ist natürlich in der Regel nicht möglich und ein erfolgreicher Angriff hängt stark von der Anwendung und der Konfiguration des XML-Prozessors (Parser) ab. Dieser sollte keine XML-Daten oder -Updates aus nicht-vertrauenswürdigen Quellen akzeptieren. Um die Definition von externen Entitäten zu unterbinden, sollte DTD deaktiviert werden. Eine Anleitung, wie dies für die einzelnen Parser geschehen kann, stellt OWASP im OWASP Cheat Sheet 'XXE Prevention' bereit, das Sie sich bei Bedarf genau anschauen sollten. Sie finden es unter (https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/XML_External_Entity_Prevention_Cheat_Sheet.md).

Das Verhindern der Eingabe unerwünschter Daten kann durch Whitelisting-Filter erreicht werden, die nur bestimmte Eingaben erlauben. Das kann z.B. durch eine Web Application Firewall (WAF) geschehen.

Essenziell ist auch hier wieder, möglichst aktuelle Versionen der Komponenten zu nutzen und regelmäßig zu patchen. Dies gilt für XML-Prozessoren, Bibliotheken und verwandte Webtechnologien wie z.B. SOAP.

OWASP empfiehlt zudem die Prüfung durch Static Application Security Testing Tools (SAST). Diese Tools analysieren den Source-Code und können wertvolle Erkenntnisse bringen. Zur Laufzeit können dann Dynamic Application Security Testing Tools (DAST) zum Einsatz kommen. Dahinter stecken nichts anderes als Vulnerability-Scanner. In jedem Fall sollte die Webanwendung, auch während der Entwicklung, von allen Seiten auf Herz und Nieren geprüft werden.

24.9   A06 – Vulnerable and Outdated Components

In den Top 10 2017 hieß diese Schwachstelle noch A09-Nutzung von Komponenten mit bekannten Schwachstellen. Hier geht es um bekannte Schwachstellen in Anwendungen, die trotzdem noch zum Einsatz kommen. Meistens sind diese Anwendungen veraltet und die Schwachstelle kann durch ein Update bzw. die Installation einer neueren Version der Anwendung bzw. der Software-Komponente beseitigt werden. Diese Schwachstelle hat große Überschneidungen mit A6 – Sicherheitsrelevante Fehlkonfiguration, aber auch mit anderen Punkten der Top-10-Liste. Sie kann ebenso auf allen Ebenen auftreten und umfasst alle an der Kommunikation im Rahmen der Webanwendung beteiligten Komponenten – angefangen von der Betriebssystemplattform über die Webserver-Software bis hin zu den eingesetzten Frameworks und sonstigen Komponenten.

24.9.1   Worin liegt die Gefahr und wer ist gefährdet?

Verwundbare Komponenten sind häufig sehr einfach auszunutzen, da es in der Regel recht schnell fertige Exploits gibt, die nur noch angewendet werden müssen – siehe Metasploit. Auch wenn maßgeschneiderter Code für den Angriff programmiert werden muss, sind professionelle Hacker oft schnell in der Lage, einen angepassten Exploit zu entwickeln.

Die Herausforderung ist, dass Webentwickler häufig auf umfassende Frameworks und Lösungen zurückgreifen, bei denen sie nicht immer vollständig verstehen, welche Komponenten und Versionen dahinterstehen und zum Einsatz kommen. Weiterhin wird die Entwicklung größerer Webprojekte oft mit bestimmten Versionen der Komponenten begonnen und während der teilweise langen Entwicklungszeit wird nicht immer sofort auf neuere Versionen aktualisiert, teilweise auch vor dem Hintergrund fehlender Kompatibilität, sodass in diesem Fall der Code teilweise angepasst werden müsste, was den Zeitrahmen sprengen würde.

Da Webentwickler (naturgemäß) nicht selten die Funktionalität einer Anwendung in den Fokus stellen und weniger die Sicherheit, obliegt es dem Projekt-Management, hier einzugreifen und Instanzen (z.B. in Form eines Sicherheitsbeauftragten) zu schaffen, die den Sicherheitsaspekt im Fokus haben und auf die Verwendung aktueller Komponenten achten. Fehlt diese Instanz, ist die Gefahr groß, dass einzelne Komponenten verwundbar sind.

In diesem Zusammenhang ist das Fehlen von Auditing-Prozessen für die Webentwicklung ein Versäumnis, das mit hoher Wahrscheinlichkeit zu Schwachstellen durch verwundbare Komponenten führt. Dies geht in der Regel mit fehlenden Prozessen für die sicherheitsrelevante Konfiguration der Komponenten gemäß A6 einher.

24.9.2   Verwundbare JavaScript-Bibliotheken aufdecken mit Retire.js

Neben den allgemein bekannten Allroundern wie Nessus und OpenVAS existieren spezialisierte Webscanner (Acunetix, Nikto2 etc.) und ähnliche Software, mit denen eine Webanwendung und ihre Komponenten auf Schwachstellen überprüft werden können. Ein beliebtes Tool ist Retire.js‌. Sie können es als Plug-in in verschiedene Browser integrieren, und auch die Burp Suite und ZAP unterstützen Retire.js. Nach der Aktivierung des Plug-ins im Browser werden automatisch verwundbare JavaScript-Bibliotheken und -Module gesucht und Funde angezeigt. Abbildung 24.32 zeigt, wie Retire.js auf das Laden der Mutillidae-Homepage reagiert und diverse Schwachstellen in der verwendeten JQuery-Version ausmacht. JQuery‌ ist die meistverwendete JavaScript-Bibilothek und dient der DOM-basierten Navigation und der Manipulation in HTML-Dokumenten. Mittlerweile sind diese Begriffe sicher schon etwas greifbarer für Sie geworden.

Abb. 24.32: Retire.js zeigt Schwachstellen in JavaScript-Bibliotheken.

Auch wenn Retire.js hier bereits diverse Schwachstellen aufführt, muss jede einzelne im Nachgang manuell überprüft werden, ob sie im aktuellen Kontext und Szenario auch tatsächlich ausgenutzt werden kann.

24.9.3   Schutzmaßnahmen

Zu den wichtigsten Schutzmaßnahmen gehört ein zuverlässiger Patchmanagement-Prozess. In diesem Zusammenhang sind insbesondere folgende Punkte bedeutsam:

• Klare Regelung der Verantwortungen. Es muss sichergestellt sein, dass eine Instanz, eine Person oder ein Team die Verantwortung für die Sicherheit der Webentwicklung und Webanwendungen übernimmt. Team heißt nicht: »Toll, ein anderer macht’s«.

• Beobachten einschlägiger Security-Bulletins. Die Security-Verantwortlichen – aber besser auch die Webentwickler – müssen sicherstellen, schnellstmöglich über entdeckte Schwachstellen informiert zu sein. Dazu bieten die Hersteller Security-Bulletins für ihre Produkte an. Darüber hinaus gibt es allgemeine Plattformen, auf denen aktuelle Sicherheitsmeldungen erscheinen. Ein guter Startpunkt hierzu ist z.B. https://www.heise.de/security. Über https://cve.mitre.org oder https://nvd.nist.gov können die Security-Verantwortlichen gezielt nach bekannten Schwachstellen für die eingesetzten Komponenten suchen. Eine weitere empfehlenswerte Maßnahme ist das Abonnieren entsprechender Mailinglisten.

• Fortlaufende Inventarisierung und Dokumentation aller eingesetzten Komponenten. Das stellt sicher, dass die Security-Verantwortlichen wissen, welche Versionen wo eingesetzt werden, und entsprechend reagieren können.

• Sicherheitstechnische Begleitung im Entwicklungsprozess. Die Prüfung der genutzten Komponenten und des selbst entwickelten Codes darf nicht erst einsetzen, wenn die Entwicklung abgeschlossen ist. Stattdessen sind eine laufende Kontrolle und ein stetiger Überwachungsprozess während der Entwicklungsphase notwendig.

Das Patchmanagement muss so gestaltet sein, dass es in kurzen Intervallen auf Updates prüft und diese einspielen kann. Wird der aktuelle Status unregelmäßig oder nur einmal alle zwei Monate geprüft, sind einzelne Komponenten unter Umständen bereits angegriffen worden und die Webanwendung damit kompromittiert. Im Gegensatz zu einigen Security-Prozessen reagieren Hacker in der Regel sehr schnell auf neue Angriffsvektoren.

24.10   A07 – Identification and Authentication Failures

Zugriffsrechte werden in fast allen Fällen in Abhängigkeit der Identität eines Benutzers erteilt. Damit steht die Authentifizierung eines Benutzers im Mittelpunkt der Sicherheitsarchitektur. Der Punkt A07 – Identification and Authentication Failures (dt. Fehler in der Identifikation und Authentifizierung) war in den OWASP Top 10 Version von 2017 noch der zweitwichtigste Angriffsvektor bei Webanwendungen, ist nun aber auf Platz 7 abgestiegen, da die zunehmende Verfügbarkeit standardisierter Frameworks hier offensichtlich die Sicherheit von Anwendungen effektiv erhöht.

24.10.1   Grundlagen

Es gibt verschiedene Ansätze, um die Authentifizierung auszutricksen. Die einfachste Methode besteht darin, dass der Angreifer die Login-Daten eines regulären Benutzers verwendet. In diesem Fall ist es für das authentifizierende System nicht erkennbar, dass der sich anmeldende Benutzer nicht autorisiert ist.

Eine ganz andere Frage ist, wie der Angreifer an die Credentials gelangt ist. Er kann sie durch Mitsniffen, Password-Cracking, Social Engineering oder über eine Technik namens Credential Stuffing‌ ermitteln. Dabei werden Credentials, die in einem anderen Zusammenhang (z.B. einem Einbruch in einer anderen Website) gestohlen wurden, auf die aktuelle Website-Authentifizierung angewendet. So werden automatisiert Anmeldeversuche mit großen Listen gestohlener Credentials durchgeführt. Dies funktioniert häufig, da Benutzer zum einen häufig E-Mail-Adressen als Anmeldenamen verwenden und zum anderen oftmals dasselbe Passwort für den Zugang zu verschiedenen Websites nutzen. Im Darknet werden riesige Listen mit Benutzerdaten zum Kauf angeboten, sodass ein Hacker keineswegs genötigt ist, selbst durch einen Einbruch an die Login-Daten zu gelangen.

Ganz grundlegend können wir also festhalten, dass das gesamte Thema »Password Hacking« bzw. »Password Cracking« in Bezug auf Webanwendungen Bestandteil der OWASP-Schwachstelle A07 – Identification and Authentication Failures) ist.

In diesem Zusammenhang können wir schon mal feststellen, dass jedes Authentifizierungsverfahren, das ausschließlich auf Benutzername/Passwort basiert, grundsätzlich angreifbar ist. Die Grundforderung ist hier also mindestens eine Zwei-Faktor-Authentifizierung.

Der Punkt A07 befasst sich jedoch nicht nur mit gefälschten Anmeldedaten, sondern auch mit fehlerhaft implementierten Authentifizierungsmechanismen. Hierzu zählen insbesondere die Session-Tokens. Im Rahmen des Session Hijackings haben wir uns bereits ausgiebig mit Session-Tokens und Cookies beschäftigt. Nachfolgend betrachten wir ein kleines Praxisszenario.

24.10.2   Identitätsdiebstahl durch Token-Manipulation

Wir werden in diesem Abschnitt eine sehr einfache Manipulation der Benutzer-Information durchführen, um das Prinzip zu verdeutlichen. Dazu verwenden wir Mutillidae und bringen die Burp Suite an den Start. Das Szenario stellt sich dar, wie in Abbildung 24.33 gezeigt.

Abb. 24.33: Zugriff via Burp Suite auf Mutillidae

Der Browser wird für die Verwendung eines Proxy-Servers unter localhost:8080 konfiguriert. Dort lauscht die Burp Suite, um jeden HTTP-Request bzw. die Response abzufangen. Dementsprechend ist Interception während des Angriffs aktiviert. Auf der Serverseite stellt der Apache-Webserver im Verzeichnis /mutillidae die VWA bereit. Sie ist unter http://192.168.1.213/mutillidae zu erreichen.

Schalten Sie den Interception-Modus für den nächsten Schritt zunächst aus, sonst wird die Prozedur etwas anstrengend, da Sie jedes HTTP-Paket explizit weiterleiten müssen.

Auf der Website erstellen Sie sich im Menüpunkt Login/Register zunächst einen normalen Benutzer (vgl. Abbildung 24.34). In unserem Beispiel lautet der Benutzername eric.

Abb. 24.34: Einen Benutzer erstellen

Melden Sie sich als dieser Benutzer an, sehen Sie rechts oben Ihren Status, wie in Abbildung 24.35 gezeigt.

Abb. 24.35: Der Benutzer ist regulär eingeloggt.

Links in der Menüleiste finden Sie den Menüpunkt Logout, um den Benutzer wieder abzumelden. Nun erfolgt der Angriff: Stellen Sie sicher, dass der Interception-Modus in der Burp Suite ab jetzt aktiviert ist, um jedes HTTP-Paket abzufangen. Melden Sie sich mit Ihrem Benutzer an und leiten Sie sorgfältig und schrittweise alle Requests weiter, bis in einem Request das Session-Cookie mit allen Benutzerdaten zu sehen ist, wie in Abbildung 24.36 dargestellt. Dort wird auch ein UID-Wert übermittelt, der hier mit 24 festgelegt ist. Testen wir aus, ob wir die Identität eines anderen Benutzers annehmen können.

Abb. 24.36: Das Session-Cookie

Klicken Sie in den UID-Wert und ändern Sie diesen auf 1 (siehe Abbildung 24.37). Klicken Sie anschließend auf Forward, um den Request weiterzuleiten.

Abb. 24.37: Anpassen der UID

Siehe da, welche Identität Sie nun angenommen haben: Plötzlich sind Sie der Admin, wie Abbildung 24.38 zeigt. Es reicht in dieser unsicher programmierten Anwendung also aus, einfach die UID im Session-Cookie anzupassen – wobei dem Admin die UID 1 zugewiesen ist (das war relativ leicht zu erraten).

Abb. 24.38: Admin-Zugang auf mutillidae

Nun können Sie z.B. über den Button rechts neben dem Benutzernamen das Passwort des Admins ändern. Denken Sie jedoch daran, für jeden Request bis zur Abmeldung die UID zu ändern, da diese vom gespeicherten Cookie immer wieder auf den ursprünglichen Wert 24 gesetzt wird. Anschließend können Sie sich direkt als Benutzer admin mit dem neuen, von Ihnen festgelegten Passwort anmelden.

24.10.3   Schutzmaßnahmen

Eine der effektivsten Maßnahmen zum Schutz vor Authentifikationsfehlern ist die Zwei-Faktor-Authentisierung (2FA). Hier wird der Angreifer dazu genötigt, beide Authentifizierungskomponenten zu fälschen, was einen erfolgreichen Angriff ungleich schwieriger macht.

Gegen die Manipulation von Session-Cookies bzw. Tokens helfen eine starke Verschlüsselung und die Wahl sicherer, nicht vorhersehbarer Session-IDs. Die Session-Verwaltung sollte unbedingt serverseitig organisiert sein und keine clientseitige Manipulation zulassen. Wir sind in Kapitel 18 Session Hijacking bereits ausführlich darauf eingegangen.

Anmeldeversuche sollten auf wenige fehlerhafte Anmeldungen beschränkt werden, sodass keine effektiven Active-Online-Angriffe möglich sind. Hier kann auch eine Zeitverzögerung eingebaut werden, die z.B. mit jedem fehlerhaften Versuch exponentiell ansteigt. Die Fehlermeldung für erfolglose Anmeldeversuche sollte nicht verraten, ob der Benutzername existiert. In diesem Zusammenhang sollten natürlich Default-Logins geändert bzw. deaktiviert werden.

Schwache Passwörter sollten bei der Festlegung durch eine entsprechende Qualitätsprüfung verhindert werden. So können Passwörter z.B. gegen Passwortlisten mit beliebten Passwörtern geprüft werden oder bestimmte Mindestanforderungen gestellt werden, wie z.B. 12 Zeichen, Groß- und Kleinbuchstaben, Sonderzeichen sowie Ziffern. Mittels Passwort-History können die letzten X Passwörter nicht erneut genutzt werden. Weitere Schutzmaßnahmen hierzu finden Sie in Kapitel 2 Password Hacking.

Im Übrigen sollten auch APIs gegen derartige Angriffe geschützt werden, um das Durchsuchen nach gültigen Benutzernamen oder anderen, sensiblen Informationen zu verhindern. Dies kann insbesondere auch wieder durch generische Fehlermeldungen ohne echte Aussagekraft erreicht werden.

24.11   A08 – Software and Data Integrity Failures

Diese Schwachstellen-Kategorie ist in den Top 10 2021 neu hinzugekommen und konzentriert sich auf Probleme im Zusammenhang mit Software-Updates, kritischen Daten und CI/CD-Pipelines, bei denen eine Integritätsprüfung fehlt oder unzureichend implementiert ist. Eigentlich handelt es sich jedoch um eine Erweiterung des Punktes A08 – Insecure Deserialization aus den OWASP Top 10 2017, der als eigener Punkt dementsprechend wegfällt. Wir führen ihn in diesem Abschnitt am Ende mit auf.

24.11.1   Was bedeutet Integritätsverletzung?

Heutige Webentwicklungen basieren auf vielen Software-Komponenten aus unterschiedlichen Quellen. Oft wird auf Plugins, Bibliotheken und Module zurückgegriffen. In der Regel werden Drittanbieter-Komponenten mit eingebunden. Eine unsichere CI/CD-Pipeline bringt die Gefahren von unbefugtem Zugriff, bösartigem Code oder einer System-Kompromittierung mit sich. CI/CD steht übrigens für Continuous Integration/Continuous Delivery und bezeichnet eine mittlerweile als Standard etablierte Form des Entwicklungsprozesses, um die Software-Entwicklung und -Bereitstellung zu optimieren.

Durch die Funktion zur automatischen Aktualisierung seitens der Anwendungen können unter Umständen Komponenten kompromittiert werden, wenn keine ausreichende Integritätsprüfung stattfindet. Gelingt es einem Angreifer, eine integrierte externe Komponente einer Software zu manipulieren, kann sein Malware-Code unter Umständen auf unzähligen Systemen auf der gesamten Welt installiert werden, wenn sich die betreffende Anwendung selbständig aktualisiert. Dies wird auch als Lieferketten-Angriff bezeichnet. Bedeutendes Opfer eines solchen Angriffs war die beliebte Software CCleaner, die im Jahr 2017 eine infizierte Drittanbieter-Komponente in den Entwicklungsprozess integriert und damit Malware auf über 2,3 Millionen Geräte, die Zugriff aufs Internet hatten, gelangte.

24.11.2   Unsichere Deserialisierung

Diese Schwachstelle ist in der Version 2017 neu hinzugekommen und jetzt bereits in einer übergeordneten Kategorie aufgegangen. Da sie dennoch an Bedeutung gewonnen hat, führen wir sie hier nach wie vor auf und stellen Ihnen die Hintergründe und Konzepte kurz vor. Auch hier geht es um eine unzureichende Integritätsprüfung, sodass die Schwachstelle unter A08 fällt.

Auch wenn das Ausnutzen von Fehlern in der Deserialisierung von Daten nicht trivial ist und vorhandener Angriffscode selten ohne weitere Anpassungen erneut eingesetzt werden kann, sind die Auswirkungen eines Exploits einer derartigen Schwachstelle unter Umständen enorm, da dies u.a. zu »Remote-Code Execution« führen kann, also dem Worst-Case-Szenario.

24.11.3   Was bedeutet Serialisierung von Daten?

Falls Sie nicht gerade aus der Webentwicklung kommen, wird Ihnen der Begriff »Serialisierung« im Kontext von Webanwendungen vielleicht nicht auf Anhieb einleuchten. Zunächst ist es heute sehr gängig, Daten in Objekten zu speichern. Objekte sind Datenstrukturen, die über Attribute verfügen.

Stellen Sie sich ein Objekt vom Typ Angestellter vor. Es enthält z.B. folgende Attribute: Name, Rolle, Wohnort, Dienstnummer (ID). Werden diese Daten normalerweise als Datensatz zusammen gespeichert, müssen sie für den Transport zwischen verschiedenen Komponenten der Webanwendung (entweder innerhalb eines Systems oder über das Netzwerk) seriell übertragen werden. Hierzu werden die Daten z.B. in ein XML-Format konvertiert, wie folgendes Beispiel zeigt:

<Angestellter><Name>Alice</Name><Rolle>Admin</Rolle><Wohnort>Berlin</Wohnort><ID>4711</ID></Angestellter> 

In dieser seriellen Form werden die Daten an die weiterverarbeitende Komponente übertragen. Dort werden sie deserialisiert, also wieder in die ursprüngliche Objekt-Datenstruktur gebracht. Diese Technik nutzt insbesondere Java, aber auch .NET, PHP und Python sind davon betroffen.

Der Vorgang der Serialisierung – und damit der potenziellen Verwundbarkeit – tritt an verschiedenen Stellen auf, z.B.

• Remote Procedure Calls

• Web Services bzw. APIs

• Cookies, Tokens oder Formulare

• Datenbanken bzw. Dateisysteme

• Caching-Vorgänge und Objektspeicherung

24.11.4   Wie wird die Deserialisierung zum Problem?

Gelingt es einem Angreifer, vor oder während der Deserialisierung Daten zu manipulieren, so kann er – je nach Szenario und Ausgangssituation – verschiedene Angriffe durchführen. Stellen Sie sich vor, es gelingt Mallory, den Namen Alice durch Mallory zu ersetzen:

<Angestellter><Name>Mallory</Name><Rolle>Admin</Rolle><Wohnort>Berlin</Wohnort><ID>4711</ID></Angestellter> 

In diesem Fall hätte Mallory aufgrund der Admin-Rolle von Alice plötzlich Administrator-Privilegien.

Serialisierung und der Gegenpart Deserialisierung ist ein vielfach durchgeführter, aber oftmals individueller Prozess, sodass es für einen Angreifer nur unter speziellen Bedingungen möglich ist, den Angriff erfolgreich durchzuführen. So muss zum einen der Input durch nicht vertrauenswürdige, externe Quellen möglich sein und zum anderen die Validierung der Daten durch den Deserialisierungsprozess unzureichend sein.

Tipp: Ein praktisches Beispiel

Ein Tool, mit dem Schwachstellen in Java-Frameworks, wie JBOSS Application Server, getestet werden können, heißt JexBoss. Sie finden die Software unter https://github.com/joaomatosf/jexboss zum kostenlosen Download für Linux, macOS und Windows. Wie ein solcher Test aussehen kann, zeigt das folgende YouTube-Video: https://www.youtube.com/watch?v=TD4zWfm0MfQ.

24.11.5   Schutzmaßnahmen

Natürlich ist auch hier wieder der eleganteste Weg, Serialisierung zu vermeiden, wo sie nicht unbedingt notwendig ist. Dies ist in vielen Fällen aber nicht möglich, da diese Art der Übertragung in vielen Szenarien Standard ist und auch viele Vorteile bietet. Wo erforderlich, können Sie versuchen sicherzustellen, dass serialisierte Objekte nicht aus nicht vertrauenswürdigen Quellen angenommen werden. Es gibt weitere Optionen, die OWASP empfiehlt:

• Serialisierte Objekte mit einer digitalen Signatur versehen. Ganz allgemein sind wir hier auch wieder bei der sicheren Übertragung von Daten und damit bei der Verschlüsselung.

• Isolieren des Programmcodes, der für die Deserialisierung zuständig ist. Wird dieser mit möglichst geringen Rechten ausgeführt, reduziert sich die Wahrscheinlichkeit, dass ein Angreifer hier größeren Schaden anrichten kann.

• Strikte Typisierung, bevor Objekte erzeugt werden. Denken Sie an XSS! Hier haben wir Variablen und Datenfelder ausgenutzt, um Daten zu hinterlegen, für die der reservierte Speicherplatz nicht gedacht war. Definieren Sie die Datenfelder also auf das notwendige Maß und stellen Sie sicher, dass nur die gewünschten Daten gespeichert werden können.

• Protokollieren aller Ausnahmefehler während der Deserialisierung. Das betrifft z.B. unerwartete Daten für definierte Objekt-Typen.

• Überwachen von Aktivitäten: Damit fällt unter Umständen auf, wenn ein Benutzer auffällig häufig eine Deserialisierung nutzt.

Auch wenn dieser Schwachpunkt zunächst wenig greifbar scheint und auch von den Penetrationstests bisher vielfach ignoriert wurde, so ist damit zu rechnen, dass er in den nächsten Jahren weiter an Bedeutung gewinnt, sodass Sie zumindest das Konzept und Prinzip verstanden haben sollten.

24.12   A09 – Security Logging and Monitoring Failures

Dieser Punkt wurde in den OWASP Top-10 2017 aufgenommen und ist ein Beitrag der Community. Im Jahr 2021 rutschte diese Schwachstelle um eins nach oben auf Platz A9. Natürlich steht das Logging & Monitoring nicht für sich allein und ist im engeren Sinne auch kein eigener Angriffsvektor – auch wenn das Spurenverwischen im Rahmen eines echten Hacking-Angriffs in der Regel ein integraler Bestandteil ist.

Andererseits bleibt festzuhalten, dass fehlendes bzw. unzureichendes Logging & Monitoring die Grundlage für fast alle größeren Sicherheitsvorfälle darstellt. Die meisten erfolgreichen Angriffe werden durch Schwachstellenscans vorbereitet. Werden diese nicht erkannt, so ist es dem Angreifer häufig möglich, einen Angriffsvektor zu ermitteln und in das Zielsystem einzubrechen. OWASP spricht hier sogar von einem fast 100-prozentigen Risiko für einen erfolgreichen Angriff.

Laut einer Studie von IBM lag die Zeit bis zur Aufdeckung eines Einbruchs im Jahr 2016 im Durchschnitt bei 191 Tagen, das sind mehr als sechs Monate! Das gibt einem Angreifer genügend Zeit, sich gründlich im Opfer-System bzw. -netzwerk festzusetzen und Schaden anzurichten. Grundsätzlich gilt: Je früher ein Angriff bzw. die Vorbereitung für einen Angriff bemerkt wird, desto besser sind die Chancen, ihn zu verhindern oder zumindest seine Auswirkungen zu verringern.

24.12.1   Herausforderungen beim Logging & Monitoring

Auch wenn das Logging und das Monitoring untrennbar zusammengehören, müssen wir dennoch zwischen beiden Vorgängen unterscheiden. Die Grundvoraussetzung für die Feststellung eines sicherheitsrelevanten Ereignisses (engl. Security Event) ist, dass die betreffende Komponente einen Log-Eintrag erzeugt. Wird ein Ereignis nirgendwo festgehalten, so kann auch niemand darauf reagieren.

Aber seien wir ehrlich: Ein Eintrag im Logfile ist zunächst mal nur eine Zeile mehr in der betreffenden Datei. Erst, wenn diese Einträge ausgelesen, analysiert und ausgewertet werden, erbringen sie einen Mehrwert. Und hier kommt das Monitoring ins Spiel. War es früher noch der Admin selbst, der mehr oder minder regelmäßig in die Logfiles geschaut hat, um Auffälligkeiten zu entdecken, ist dieser Prozess in modernen, größeren Umgebungen mittlerweile häufig automatisiert. Es existieren diverse Logging-Verwaltungstools, die auf sicherheitsrelevante Events spezialisiert sind. Dabei handelt es sich um sogenannte SIEM‌-Tools, wobei SIEM für Security Information and Event Management steht. Sie sind in der Lage, Logdaten von allen relevanten Systemen im Netzwerk der Organisation zu sammeln, auszuwerten und in Korrelation zu setzen. Werden sicherheitsrelevante Ereignisse festgestellt, können entsprechende Alarme via E-Mail, SMS oder Popups erzeugt werden, die den Verantwortlichen die Möglichkeit geben, umgehend zu reagieren.

Ein Beispiel, in dem klar wird, wo intelligente SIEM-Systeme der manuellen Analyse gegenüber im Vorteil sind, ist Credential Stuffing‌. Wir haben diesen Angriff bereits früher vorgestellt. Dabei werden große Listen mit an anderer Stelle gestohlenen Account-Daten abgearbeitet und getestet, ob die Login-Daten auch beim Opfer-System funktionieren. Da jeder Account – existent oder nicht – in diesem Fall nur einmal geprüft wird, schlagen Systeme, die bei einem bestimmten Threshold-Wert von z.B. drei oder fünf fehlgeschlagenen Logins aktiv werden, noch keinen Alarm. Die deutlich erhöhte Anzahl an Login-Versuchen würde aber ein SIEM-System sofort erkennen können.

Damit ein solches System zuverlässig funktioniert, ist jedoch elementar, dass

• das betreffende System die richtigen Daten in der richtigen Art und Weise protokolliert (es gibt sowohl zu wenig als auch zu viel des Guten, hier ist das Tuning des Loglevels gefragt),

• die Daten in Echtzeit oder sehr zeitnah an das SIEM-System weitergeleitet werden,

• das SIEM-System möglichst wenig False Positives und noch weniger False Negatives produziert, dies erfordert ein gewisses Maß an Tuning,

• der Angreifer nicht an die Logdaten herankommt, um diese zu manipulieren.

Eine andere enorm wichtige Komponente ist in diesem Zusammenhang das Intrusion-Detection- bzw. -Prevention-System (IDS/IPS). Es untersucht die Kommunikation in Echtzeit und kann im Falle des IPS nicht nur Alarm schlagen, sondern auch gleich die unerwünschte und ggf. gefährliche Kommunikation blockieren. Aber auch diese Systeme müssen gewartet, regelmäßig aktualisiert und getunt werden, damit sie zuverlässig in der jeweiligen Umgebung funktionieren.

Eine weitere potenzielle Schwachstelle ist der menschliche Faktor (engl. Human Factor). Es wäre nicht das erste Mal in der Geschichte der Sicherheitsvorfälle, in denen das Monitoring-Tool vorbildlich vor einem Angriff warnt und die Sicherheitsverantwortlichen keinen Plan haben, wie sie reagieren müssen. Hier sind klare Prozesse, Sensibilisierung und regelmäßige Übungen essenziell.

24.12.2   Sind unserer Systeme gefährdet?

Der beste Test der eigenen Umgebung ist die Probe aufs Exempel: Führen Sie im Rahmen von Penetration-Tests Angriffe wie Portscans oder Wörterbuch-Angriffe durch, um die Reaktion Ihrer Systeme zu überprüfen:

• Werden alle relevanten Informationen protokolliert? Insbesondere erfolgreiche und erfolglose Anmeldeversuche müssen gemeldet werden.

• Werden diese Informationen in Echtzeit an einen zentralen Logserver bzw. ein Monitoring-System weitergeleitet?

• Sind alle wichtigen Systeme am zentralen Monitoring angeschlossen?

• Existieren geeignete Alarmierungs-Schwellen (engl. Thresholds), wie z.B. bei gehäuften Anmeldeversuchen?

• Erzeugen Vulnerability-Scanner und Portscanner entsprechende Warnungen?

• Reagieren die Sicherheitsverantwortlichen korrekt auf nicht angekündigte Angriffstests?

• Wird effektiv verhindert, dass ein Angreifer Zugriff auf die Logdaten erhält, um diese zu manipulieren? Hier hilft ggf. auch ein Integritätsschutz via Hashfunktion.

• Werden die Logdaten lange genug aufgehoben, sodass auch eine nachträgliche forensische Analyse möglich ist?

• Sind alle wichtigen Notfallprozesse klar definiert und schriftlich fixiert, von der Geschäftsleitung abgesegnet und allen Beteiligten bekannt?

Auch hier ist OWASP wieder mit einem umfassenden Dokument als Leitfaden behilflich, das unter https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Logging_Cheat_Sheet.md verfügbar ist.

24.13   A10 – Server-Side Request Forgery (SSRF)

Auch dieser letzte Punkt der OWASP Top 10 2021 ist aus der Community eingeflossen und neu dabei. Vermutlich wird diese Schwachstelle in Zukunft auch in anderen Punkten aufgehen, aber für die aktuelle Fassung der OWASP Top 10 nimmt sie eine eigene Position ein. Laut OWASP ist die Inzidenz-Rate derzeit noch relativ niedrig, aber der Angriffsvektor hat ein hohes Schadpotenzial und ist an sich auch gar nicht neu.

24.13.1   Wie funktioniert SSRF?

SSRF basiert darauf, dass eine Webanwendung eine Ressource auf einem anderen System abruft, ohne die vom Benutzer angegebene URL zu prüfen. Dabei ist es dann z.B. möglich, statt des Inhalts des Benutzer-Warenkorbs die gesamte User-Liste abzurufen. Im Ergebnis funktioniert SSRF also ähnlich wie ein Injection-Angriff: Der Angreifer manipuliert den Request-String, den der Server ungeprüft übernimmt und dadurch eine andere Anfrage als eigentlich vorgesehen an die dahinterliegende Komponente weitergibt. Im Ergebnis passieren dann ganz andere Dinge, als von den Entwicklern der Anwendung beabsichtigt wurden. Wichtig ist, dass der direkte Zugriff aufgrund der fehlenden Vertrauensstellung zwischen dem User und dem dritten System hinter dem Webserver nicht möglich wäre, da z.B. eine Firewall die direkte Kommunikation blockiert. Es werden also zum einen die fehlende Validierung des User-Requests und zum anderen die Vertrauensstellung zwischen dem Webserver und einer dritten Komponente ausgenutzt.

Abb. 24.39: Kommunikation bei einem SSRF-Angriff

Im Beispiel in Abbildung 24.39 holt sich der Webserver bei einem entsprechenden User-Request Daten von einem internen Server. Wird der Request manipuliert und nicht ausreichend geprüft, liefert der interne Server Daten, die nicht vorgesehen sind. Statt eines internen Servers kann die Datenquelle aber auch externer Art sein, das Prinzip ist das gleiche. Genau genommen kann die Datenquelle auch auf dem Webserver selbst liegen.

24.13.2   Ein SSRF-Beispiel

Ein einfaches Praxisbeispiel können Sie in der PortSwigger Academy durchspielen. Portswigger ist das Unternehmen, das die Burp Suite entwickelt und bereitstellt. Die Academy ist kostenlos und sehr empfehlenswert. Erstellen Sie sich unter https://portswigger.net einen Academy Account und starten Sie das Lab Basic SSRF against local server über einen Browser in Kali Linux. Wie in der Lab-Beschreibung zu lesen ist, kann eine Abfrage des aktuellen Bestandes (stock) vorgenommen werden. Dazu öffnen Sie ein Produkt im Lab-Webshop und können unten dann eine Stock-Abfrage durchführen (siehe Abbildung 24.40).

Abb. 24.40: Abfrage des Stocks

Diesen Request werden wir nachfolgend manipulieren und einen SSRF-Angriff durchführen. Das Ziel des Angriffs ist es, die Admin-Seite zu erreichen, die derzeit nicht direkt aufgerufen werden kann und dort den User carlos zu löschen. Hängen Sie an die URL des Web-Labs /admin an, erhalten Sie einen Hinweis, dass der Aufruf nur über die Loopback-Adresse (127.0.0.1) bzw. nur vom eingeloggten User Admin erfolgen kann (siehe Abbildung 24.41).

Abb. 24.41: Zugriff auf die Admin-Seite der Lab-Anwendung ist nicht möglich

Wichtig! CA-Zertifikat der Burp Suite importieren

Bevor Sie starten, müssen Sie sicherstellen, dass die Burp Suite gestartet wurde und aktiv ist, und das Burp Suite-Zertifikat in Ihren Browser importieren. Dazu öffnen Sie unter Verwendung der Proxy-Einstellungen für die Burp Suite die Seite http://burpsuite und klicken ganz rechts auf CA Certificate, um dieses CA-Zertifikat zu importieren. Damit wird die Burp Suite HTTPS-fähig.

Damit sind wir startklar. Aktivieren Sie die Proxy Interception und starten Sie den Request zur Abfrage eines Stocks, wie in Abbildung 24.40 gezeigt. Die Burp Suite fängt den Request ab, der sich wie in Abbildung 24.42 darstellt.

Abb. 24.42: Der Original-Request zur Abfrage des Bestandes

Es handelt sich um einen POST-Request auf /product/stock und im Body steht der Wert für stockApi. Das ist die angesprochene URL, die der Server kontaktieren soll, um die gewünschten Daten zu abzufragen. Sie ist nur vom Server erreichbar. Da es sich um eine URL-Codierung handelt, können Sie den Wert hinter dem Gleichheitszeichen markieren und über Rechtsklick Send to Decoder auswählen. Im Decoder-Modul der Burp Suite können Sie unter Decode as … URL auswählen, um die konkrete Klartext-URL für die externe API anzeigen zu lassen (siehe Abbildung 24.43).

Abb. 24.43: Die URL in Klartext

Das ist allerdings nur zur Information, wir werden mit diesem Wert aktuell nicht weiterarbeiten. Stattdessen klicken Sie rechts auf den Request im Proxy und wählen Send to Repeater – das kennen Sie ja bereits. Im Repeater können wir den Wert für stockApi in http://127.0.0.1/admin ändern. Da der Doppelpunkt codiert werden muss, empfiehlt es sich, über das Kontextmenü des Repeaters URL-encode as you type zu aktivieren, bevor Sie die URL wie oben eingeben.

Schicken Sie diesen Request so ab, erhalten Sie eine Antwort des Servers mit jeder Menge HTML-Code. Das sieht gut aus. Klicken Sie im Response-Fenster rechts auf Render, um sich die zurückgelieferte HTML-Seite anzeigen zu lassen. Sie stellt sich dar wie in Abbildung 24.44 gezeigt.

Abb. 24.44: Der Webserver liefert die geschützte Admin-Seite.

Diese Seite konnte aufgerufen werden, da der Webserver die im POST-Request übermittelte, manipulierte URL nicht korrekt geprüft hat. Nun können wir den User carlos löschen, um die Aufgabe zu erfüllen. Dazu analysieren wir den Delete-Button hinter dem Usernamen. Lassen Sie sich also die Webseite über den Reiter Pretty wieder als HTML anzeigen und suchen Sie nach »Delete«. Der dazugehörige Link lautet /admin/delete?username=carlos. Wir ändern die URL im Repeater hinter stockApi wie folgt ab:

http://localhost/admin/delete?username=carlos 

Senden Sie den Request in dieser Form erneut ab, wird der User gelöscht. Das können Sie testen, indem Sie anschließend erneut http://127.0.0.1/admin aufrufen. Auf der zurückgelieferten Webseite wird bestätigt, dass der User erfolgreich gelöscht und das Lab gelöst wurde (siehe Abbildung 24.45). Herzlichen Glückwunsch!

Abb. 24.45: User carlos gelöscht, Lab gelöst

Und die Schutzmaßnahmen? Wie bereits erwähnt ist auch hier wieder eine Eingabevalidierung erforderlich, sodass der Webserver die übermittelte URL nicht einfach ungeprüft übernimmt und ausführt. Auch die Firewall kann hier ggf. unterstützen, indem die vom Webserver weitergeleiteten Requests entsprechend eingeschränkt werden.

24.14   Zusammenfassung und Prüfungstipps

Werfen wir wieder einen Blick zurück: Was haben Sie gelernt, wo stehen Sie und wie geht es weiter?

24.14.1   Zusammenfassung und Weiterführendes

In diesem Kapitel haben wir uns mit den wichtigsten Angriffsvektoren auf Webanwendungen beschäftigt. Sie sind in der OWASP-Top-10-Liste erfasst. OWASP ist eine gemeinnützige Organisation mit dem Ziel, die Sicherheit von Webanwendungen zu verbessern. Dazu werden viele Projekte mit unterschiedlichen Zielen von OWASP betrieben. Angefangen von Sicherheitsdatenblättern und diversen Leitfäden über Angriffstools, Dokumentationen, Templates, Frameworks, Code-Projekte.

Mit Mutillidae II stellt OWASP neben dem Juice Shop sogar eine eigene Vulnerable Web Application (VWA) bereit, mit der Schwachstellen trainiert werden können. Darüber hinaus gibt es zahlreiche andere VWAs, wie z.B. WebGoat, bWAPP oder DVWA.

Web-Hacking gehört zu den umfassendsten Themen des Hackings überhaupt, da die meisten heutigen Anwendungen auf Webtechnologien basieren. Es existieren zahlreiche Webserverprodukte, Frameworks und APIs, die von diversen Programmiersprachen, wie Java, PHP, Perl, Python, Ruby und vielen anderen genutzt werden können. Die Vielfalt ist nahezu unüberschaubar.

Aus diesem Grund können wir in diesem Buch an vielen Stellen nur an der Oberfläche kratzen und müssen uns damit begnügen, Ihnen die wichtigsten Grundlagen und Konzepte anhand kleiner, einfacher Beispiele zu vermitteln. Möchten Sie jedoch tiefer in die Materie einsteigen, bleibt es Ihnen nicht erspart, diverse Webtechnologien und Sprachen wie Java und JavaScript sowie PHP zumindest in den Grundzügen zu erlernen, um eine Schwachstellenanalyse vornehmen zu können, bevor Sie einen Angriff auf die verwundbare Komponente planen können.

Im nächsten Kapitel geht es nun weiter mit Injection-Angriffen, die mit A03 in der Version 2021 noch immer weit oben auf der Top-10-Liste von OWASP stehen. Sie stellen nach wie vor eine große Gefahr für Webanwendungen dar. Anschließend werden wir uns noch mit weiteren Angriffen auf Webanwendungen beschäftigen, sodass Sie nach der Lektüre dieses Buches zumindest eine gute und umfassende Vorstellung von den zahlreichen Angriffsformen auf Webserver und -anwendungen haben werden und bereit sind für die nächsten, eigenständigen Schritte.

24.14.2   CEH-Prüfungstipps

Zunächst einmal stellen Sie sicher, dass Sie alle beschriebenen Angriffsformen und insbesondere auch die spezifische Terminologie verstanden und verinnerlicht haben.

Des Weiteren empfehlen wir, die Aufgaben und Übungen innerhalb der VWAs durchzuarbeiten. Denken Sie daran, in Ihrem eigenen Labor zu experimentieren, und nutzen Sie die Möglichkeit, die »Was-passiert-dann-Maschine« anzuwerfen. Sammeln Sie damit Erfahrung in der Praxis, denn nichts festigt sich besser als Inhalte, die man sich selbst erarbeitet hat.

Viele Prüfungsfragen nehmen die Sicht des Verteidigers ein. Schauen Sie sich die Prevention Sheets auf der OWASP-Seite an und studieren Sie die Konzepte der Schutzmaßnahmen für die jeweiligen Angriffsformen.

24.14.3   Fragen zur CEH-Prüfungsvorbereitung

Mit den nachfolgenden Fragen können Sie Ihr Wissen überprüfen. Die Fragestellungen sind teilweise ähnlich zum CEH-Examen und können daher gut zur ergänzenden Vorbereitung auf das Examen genutzt werden. Die Lösungen zu den Fragen finden Sie in Anhang A.

1. Emil ist ein Black Hat Hacker und hat in einem Gästebuch einer Webseite statt eines regulären Gästebuch-Eintrags einen JavaScript-Code eingetragen, der ihm das Session-Cookie eines Opfers liefern soll, das das Gästebuch aufruft. Wie nennt sich dieser Angriff?

   1. CSRF

   2. XSS

   3. Session Hijacking

   4. Injection-Angriff

2. Was wird mit »unsicherer Deserialisierung« bezeichnet?

   1. Eine Schwachstelle, bei der der Browser extern eingeschleuste Skripts ausführt und damit vertrauliche Informationen preisgibt.

   2. Wird eine nacheinander durchgeführte Zugriffskontrolle nicht korrekt ausgewertet, spricht man von unsicherer Deserialisierung.

   3. Ist es einem Angreifer möglich, z.B. in XML-Daten, die an eine API geschickt werden, Werte zu manipulieren, die bei der Auswertung dieser Daten nicht als verändert identifiziert werden, liegt eine Schwachstelle in der Deserialisierung vor.

   4. Die Deserialisierung sorgt für eine strukturierte Organisation von Daten einer Webpräsenz. Ist dieser Prozess angreifbar, sprechen wir von unsicherer Deserialisierung.

3. IDOR (Insecure Direct Object References) ist eine Angriffsform, bei der z.B. in XML-Dateien auf bösartige externe Quellen referenziert wird. Welcher der folgenden Angriffe stellt ein Beispiel für IDOR dar?

   1. DVWA

   2. XSS

   3. CSRF

   4. XXE

   5. LFI

4. Welche der im Folgenden genannten Sicherheitsmaßnahmen schützt effektiv gegen Injection-Angriffe auf Webanwendungen?

   1. WAF

   2. Least Privileges

   3. Web Security Policy

   4. Web-Proxy

5. OWASP Top 10 stellt eine priorisierte Liste mit den wichtigsten Web-Angriffen bereit. Welche der nachfolgenden Angriffsformen ist nicht in den OWASP Top 10 2021 vertreten?

   1. Broken Access Control

   2. Injection

   3. Cross-Site-Scripting (XSS)

   4. Vulnerable and Outdated Components

   5. Security Misconfiguration