Secure Coding

Module

M08: Integritätsfehler in Software oder Daten

Herkunft und Unversehrtheit von Daten und Artefakten prüfen, bevor sie angenommen werden. Aufgabe 1 verändert gespeicherte Inhalte, die Aufgaben 2 und 3 führen fremden Code aus, die Aufgaben 4 und 5 fälschen Tokens.

Für die Aufgaben 2 und 3 zuerst die veraltete B2B-REST-API finden. Möglicherweise gibt es dazu eine Swagger-Dokumentation …

Nur die Aufgaben 2 und 3 sind unter Docker simuliert. Mit --env NODE_ENV=unsafe beim Docker-Run werden sie tatsächlich ausnutzbar.

  1. Aufgabe 01

    Produktbeschreibung manipulieren

    Im Produkt „OWASP SSL Advanced Forensic Tool (O-Saft)“ das Ziel des Links in der Beschreibung auf https://owasp.slack.com ändern.

    Theoretisch gibt es drei Wege: kaputte Admin-Funktion, Löcher in der REST-API oder SQL Injection.

    In der Praxis führen zwei dieser drei Wege in die Sackgasse.

    Erst ansehen, welche HTTP-Verben die Produkt-API überhaupt zulässt.

    Kernfrage des Moduls: Wer darf gespeicherte Inhalte ändern – und würde jemand merken, dass sie geändert wurden?

  2. Aufgabe 02

    Remotecodeausführung, die eine schwächere Anwendung dauerhaft auslasten würde

    Eine Remote Code Execution ausführen, die eine weniger gehärtete Anwendung endlos beschäftigen würde – nicht per Request-Flut.

    Die nötige Funktion wird nirgendwo beworben. Der Juice Shop hat eine veraltete B2B-Schnittstelle; die zuerst finden.

    Weil der Shop in JavaScript geschrieben ist, liegt ein bestimmtes Datenformat für die Serialisierung nahe.

    Ziel ist, den Server „für alle Ewigkeit“ zu beschäftigen.

    Die Aufgabe zählt, wenn der Schutz gegen genau diesen Endlosschleifen-Vektor ausgelöst wird.

    Den Server mit Anfragen zu bombardieren (klassisches DoS) löst sie nicht. Das würde eher die Instanz umlegen.

  3. Aufgabe 03

    Remotecodeausführung ohne Endlosschleife, die den Server eine Weile beschäftigt

    Eine Remote Code Execution ausführen, die den Server eine Weile beschäftigt – ohne Endlosschleife.

    Der Ansatzpunkt ist derselbe wie bei der Aufgabe darüber. Diesmal ohne Endlosschleife.

    Der Payload darf den Schutz gegen zu viele Iterationen nicht auslösen. Die Aufgabe wird als gelöst markiert, der Shop bleibt aber erreichbar.

  4. Aufgabe 04

    Unsigniertes JWT erstellen

    Ein im Wesentlichen unsigniertes JWT erstellen, das sich als der nicht existierende Benutzer jwtn3d@juice-sh.op ausgibt.

    Die Aufgabe nutzt eine merkwürdige Option, die beim Signieren von JWTs unterstützt wird.

    Zuerst ein gültiges JWT aus dem Authorization-Header eines eingeloggten Requests holen.

    JWTs gibt es nur für angemeldete Konten, und sie laufen ab – also nicht trödeln.

    https://jwt.io/ hat einen praktischen Debugger, der bei dieser Aufgabe oft den Unterschied macht.

    Die Anwendung dazu bringen, ein Token mit dem nötigen Payload als gültig zu akzeptieren – und dabei auf „keine Signatur“ herunterzustufen.

    Darauf achten, dass das JWT URL-safe ist (Base64url, nicht gewöhnliches Base64).

  5. Aufgabe 05

    RSA-signiertes JWT erstellen und sich als rsa_lord@juice-sh.op ausgeben

    Ein gültiges JWT erstellen, das fast wie mit RSA signiert aussieht und sich als der nicht existierende Benutzer rsa_lord@juice-sh.op ausgibt.

    Es geht ausdrücklich nicht darum, den privaten RSA-Schlüssel zu beschaffen.

    Die allgemeinen Hinweise der Aufgabe zum unsignierten JWT gelten hier ebenfalls.

    Statt zu erzwingen, dass gar nicht signiert wird, braucht es einen aufwendigeren Angriff gegen die JWT-Bibliotheken im Juice Shop.

    Der öffentliche RSA-Schlüssel, den die Anwendung für JWTs nutzt, ist für diese Aufgabe zwingend.

    Den passenden privaten Schlüssel zu finden sollte eigentlich unmöglich sein – unlösbar ist die Aufgabe trotzdem nicht.

    Darauf achten, dass das JWT URL-safe ist.

    Unter Windows (nativ, nicht Linux-Docker) blendet der Juice Shop diese Aufgabe aus.