Secure Coding

Module

M10: Security Logging und Exceptional Conditions

Offene Telemetrie, uneinheitliche Fehlerbehandlung, eine Race Condition, fehlende Upload-Grenzen. Logs können an Stellen landen, an die sie nicht gehören.

Aufgabe 6 nutzt denselben Poison-Null-Byte-Trick wie M03, Aufgabe 2, diesmal auf eine andere Datei.

  1. Aufgabe 01

    Fehler provozieren, der weder elegant noch einheitlich behandelt wird

    Einen Fehler auslösen, den die Anwendung weder elegant noch einheitlich behandelt.

    Ungültige Eingaben in Formulare schicken. Alternativ URL-Pfade oder Parameter verdrehen.

    Die Aufgabe löst sich über mehrere mögliche Fehlerzustände.

    Schlechte Eingaben in Formularen provozieren oft eine unsaubere Fehlerbehandlung.

    Manipulierte URL-Pfade oder Parameter können ebenfalls einen unerwarteten Fehler auslösen.

  2. Aufgabe 02

    Dieselbe Review mindestens dreimal liken

    Eine Review mindestens dreimal als derselbe Nutzer liken. Die Anwendung ordnet Likes einem Konto zu – das soll Mehrfach-Likes verhindern.

    Pünktlichkeit ist die Höflichkeit der Könige.

    Jeder Nutzer wird (fast) sofort mit der gelikten Review verknüpft, um Missbrauch zu verhindern.

    Dreimal schnell hintereinander auf Like klicken reicht für eine Sechs-Sterne-Aufgabe nicht.

    Die zugrunde liegende Lücke ist eine Race Condition.

  3. Aufgabe 03

    Metrics-Endpunkt finden

    Den Endpunkt finden, der Nutzungsdaten für ein gängiges Monitoring-System ausliefert.

    Raten, unter welcher URL der Endpunkt liegen könnte.

    Der Juice Shop liefert die Metrics auf dem Standardpfad, den Prometheus erwartet.

    Den Pfad zu raten ist oft schneller als die Doku. Alternativ: https://prometheus.io/docs/introduction/first_steps

  4. Aufgabe 04

    Datei größer als 100 kB hochladen

    Eine Datei hochladen, die größer als 100 kB ist – obwohl die Anwendung das verhindern soll.

    Unter Beschwerde / Complaint lässt sich eine kleine Datei anhängen. Erst verstehen, wie dieser Upload wirklich funktioniert.

    Getrennt betrachten, was der Client prüft und was der Server prüft.

    Die Grenze steht an einer Stelle, an der sie sich umgehen lässt.

    Das ist die A10-Seite dieses Moduls: eine Grenze, die nicht fail-closed durchgesetzt wird.

  5. Aufgabe 05

    Zugriff auf Log-Datei

    Normalerweise liegen Server-Logs auf der Festplatte und sind von außen nicht erreichbar. Zugriff auf ein Access-Log des Servers verschaffen.

    Wer kommt auf die Idee, ein Access-Log über die Webanwendung auszuliefern?

    Eine bestimmte Datei unter /ftp bringt weiter.

    Ein Verzeichnis tiefer ins Dateisystem reicht oft noch nicht.

    Im Log stehen Requests anderer Nutzer. Genau deshalb gehört es nicht ins Web.

  6. Aufgabe 06

    Verlegte SIEM-Signaturdatei finden

    Eine Signaturdatei für das SIEM abrufen, die am falschen Ort liegt.

    Es geht wieder darum, einer Sicherheitsprüfung eine erlaubte Dateiendung vorzugaukeln.

    Wer eine der Datei-Aufgaben in M03 gelöst hat, weiß schon, wo die Datei liegt.

    Denselben Trick einfach nochmal anwenden – auf die Signaturdatei.

    Interessant ist der Inhalt: dort steht, welche Angriffe überhaupt erkannt werden würden. Und welche nicht.

  7. Aufgabe 07

    Geleaktes Passwort im Netz finden und einloggen

    Ein geleaktes Passwort im Internet finden und sich damit im ursprünglichen Konto anmelden. Ein neues Konto mit demselben Passwort zählt nicht.

    Gesucht sind geleakte Access-Logs in einem recht verbreiteten Format.

    Eine sehr populäre Hilfe-Plattform für Entwickler enthält Brotkrumen zur Lösung.

    Das eigentliche Log wurde auf eine Plattform kopiert, über die man Daten schnell mit Externen oder Kollegen teilt.

    Mit dem Fund aus dem Log führt Password Spraying zum Ziel.

    Die Lehre für dieses Modul: Logs enthalten Zugangsdaten, wenn niemand definiert hat, was nicht geloggt werden darf.