Module

M01: Injection

Bevor wild Payloads durchprobiert oder eine Angriffsliste abgearbeitet wird: erst klären, ob überhaupt eine Lücke da ist – und wo. Mit einem Payload, der eine SQL-Abfrage typischerweise abbricht (z. B. ' oder ';--), lässt sich ein Fehler provozieren. Die Anwendung verrät dabei oft die Abfragestruktur und Schema-Details, etwa Tabellen- oder Spaltennamen.

Injection trifft jeden Interpreter, der Daten als Anweisung liest: Aufgabe 6 eine NoSQL-Datenbank, Aufgabe 7 ein Sprachmodell und Aufgabe 8 eine Template-Engine auf dem Server.

Aufgabe 7 braucht den LLM-Chat des Juice Shops. Aufgabe 8 ist unter Docker nur simuliert; mit --env NODE_ENV=unsafe beim Docker-Run wird sie tatsächlich ausnutzbar.

  1. Score Board finden

    Die sorgfältig versteckte Score-Board-Seite finden. Ohne sie gibt es weder Fortschritt noch die Übersicht, welche Aufgaben noch offen sind.

    Diese Aufgabe wird nicht per SQL Injection gelöst.

    In der Oberfläche gibt es keinen Link dorthin. In den Quelltext schauen – die Seite ist nur schlecht versteckt.

  2. Aufgabe 02

    Log in mit Admin-Account

    Was wäre eine anfällige Webanwendung ohne ein Administratorkonto, dessen (angeblich) privilegierte Zugriffsrechte ein erfolgreicher Hacker missbrauchen kann?

    Der Titel sagt ziemlich klar, welches Formular anzugreifen ist.

    Ist die E-Mail-Adresse des Admins schon bekannt (admin@juice-sh.op), gezielt vorgehen.

    Auch ohne die Adresse kann ein allgemeines Injection-Muster funktionieren.

    Liegt der Passwort-Hash des Admins vor, lässt er sich natürlich auch angreifen – das ist hier aber nicht der erwartete Weg.

  3. Aufgabe 03

    Log in mit Benders Account

    Bender ist Stammkunde, hängt im Juice Shop aber vor allem herum, um ihn wegen der fehlenden alkoholischen Getränke zu trollen.

    E-Mail-Schema: user@juice-sh.op

    Der Titel sagt, welches Formular anzugreifen ist.

    Für einen gezielten Angriff braucht es Benders E-Mail-Adresse (bender@juice-sh.op).

    Falls etwas anderes als SQL Injection versucht wird: Benders Passwort-Hash hilft hier kaum.

  4. Aufgabe 04

    "Christmas special offer of 2014" bestellen

    Das Weihnachtsangebot von 2014 bestellen – ein Produkt, das im Shop inzwischen nicht mehr angeboten wird.

    Herausfinden, wie die Anwendung nicht verfügbare und gelöschte Produkte vor Kunden verbirgt.

    Einen Angriffsstring bauen, der gelöschte Produkte wieder in der Trefferliste zeigt.

    Das gelöschte Produkt in den Warenkorb legen und bis zum Checkout gehen.

    Über die normale Oberfläche geht das nicht. HTTP-Requests und -Responses mitlesen hilft; oft ist (halb-)blinde SQL Injection nötig.

  5. Aufgabe 05

    Alle Anmeldedaten per SQL Injection holen

    Per SQL Injection eine Liste aller Anmeldedaten ziehen.

    Einen API-Aufruf finden, bei dem sich beeinflussen lässt, welche Daten zurückkommen.

    Mit einem UNION SELECT Daten aus einer anderen Tabelle ins ursprüngliche Ergebnis holen.

    Die SQL-Syntax oft Schritt für Schritt reparieren: von einem Fehler zum nächsten.

    Wie beim Christmas Special geht das nicht über die normale Oberfläche.

  6. Aufgabe 06

    Mehrere Produkt-Reviews gleichzeitig ändern

    Alle Bewertungen eines Produkts mit einem einzigen Request umschreiben – nicht eine nach der anderen.

    Die Reviews liegen in einer anderen Datenbank als die Konten. Der Interpreter ist hier MongoDB.

    Erst ansehen, wie eine einzelne Review über die API geändert wird.

    Nachlesen, wie Updates und Query-Operatoren in MongoDB funktionieren.

    Über die normale Oberfläche geht das nicht. Request abfangen und den Body anpassen.

  7. Aufgabe 07

    Chatbot per Prompt Injection zu einem Coupon überreden

    Den Support-Chatbot dazu bringen, einen Coupon zu erzeugen – obwohl seine Coupon-Regeln das eigentlich nicht vorsehen.

    Der Interpreter ist hier das Sprachmodell. Der Bruch ist derselbe: Daten werden als Anweisung gelesen.

    Der Chatbot hat ein Werkzeug für Coupons, darf es laut Anweisung aber nur unter sehr engen Bedingungen nutzen.

    Den Chatbot davon überzeugen, dass die Bedingungen erfüllt sind – auch wenn sie es nicht sind.

    Antwortet der Chat nicht, ist das angebundene Modell nicht aktiv. Dann ist die Aufgabe nicht lösbar.

  8. Aufgabe 08

    Server Side Template Injection zur Codeausführung

    Über eine Template-Auswertung auf dem Server Code ausführen und den Shop mit der harmlosen Übungs-Malware infizieren.

    SSTi hat nichts mit Angular zu tun: hier wertet eine Template-Engine auf dem Server einen String aus dem Request aus.

    Nur die harmlose Übungs-Malware verwenden, die zum Juice Shop gehört.

    Die Malware findet sich über eine naheliegende Suche im Netz – oder in einem schlecht platzierten Quarantäne-Ordner, in dem die nötigen URLs stehen.

    Ziel ist, dass der Server die Malware selbst herunterlädt und ausführt.

    Reverse Engineering der Malware ist hier nicht nötig. Das kommt erst bei der SSRF-Aufgabe in M05.

    Sechs Sterne, unter Docker nur mit --env NODE_ENV=unsafe. Eher Take-home oder Trainer-Demo.