Bedrohungen in einem einfachen Login-Dienst abbilden

CybersicherheitBeginner
Jetzt üben

Einführung

Threat Modeling (Bedrohungsmodellierung) ist eine praktische Methode, um potenzielle Schwachstellen eines Systems zu analysieren, bevor es angegriffen wird. Anstatt direkt mit Tools zu arbeiten, identifizieren Sie zunächst, was geschützt werden muss, wo Daten Vertrauensgrenzen überschreiten, wie sich ein Angreifer im System bewegen könnte und welche Kontrollmechanismen das Risiko minimieren.

In diesem Lab untersuchen Sie einen kleinen lokalen Login-Dienst und vervollständigen ein strukturiertes Bedrohungsmodell in der Datei security-model.json. Das Modell ist kein freier Bericht: Jeder Schritt fügt spezifische JSON-Einträge hinzu, die durch ein Validierungsskript überprüft werden können.

Den Login-Dienst untersuchen

In diesem Schritt untersuchen Sie den kleinen Dienst, den Sie modellieren werden. Ein Bedrohungsmodell beginnt bei beobachtbarem Systemverhalten: Was tut die Anwendung, welche Dateien verwendet sie und welche Informationen könnten für einen Angreifer von Bedeutung sein?

Wechseln Sie zunächst in das Projektverzeichnis:

cd /home/labex/project

Listen Sie die vorbereiteten Dateien auf:

ls -l

Sie sollten Dateien wie app.py, users.json, sessions.json, security-model.json sowie das Verzeichnis uploads sehen.

Lassen Sie sich nun die Routen der Demo-Anwendung anzeigen. Eine Route ist ein Einstiegspunkt der Anwendung, der Anfragen entgegennimmt:

python3 app.py routes

Die Ausgabe sollte vier Routen anzeigen:

/login - akzeptiert Benutzername und Passwort und erstellt ein Sitzungs-Token
/files - listet Dateien auf, die dem angemeldeten Benutzer gehören
/download - liest einen angeforderten Dateinamen aus dem uploads-Verzeichnis
/admin - zeigt Kontodatensätze nur für Administratoren an

Führen Sie abschließend den aktuellen Modell-Checker aus. Er wird fehlende Abschnitte melden, da das Modell absichtlich leer ist:

python3 model-check.py all

Sie sollten Meldungen sehen, dass in jedem Abschnitt erforderliche Einträge fehlen. Dies ist der Ausgangspunkt für den Rest des Labs.

Die Assets identifizieren

In diesem Schritt fügen Sie dem Modell Assets hinzu. Beim Threat Modeling ist ein Asset alles, was das System schützen muss. Für diesen Login-Dienst sind nicht nur Dateien wichtig, sondern auch Authentifizierungsdaten und der Sitzungsstatus.

Verwenden Sie cat, um die Benutzerdatenbank zu untersuchen:

cat users.json

Die Datei enthält Benutzernamen, Passwörter und Rollen. Das macht user_credentials und admin_records zu wichtigen Assets.

Untersuchen Sie die Sitzungsdatei und das uploads-Verzeichnis:

cat sessions.json
ls -l uploads

Die Sitzungsdatei kann Login-Token enthalten, und das Verzeichnis uploads enthält private Benutzerinhalte. Diese entsprechen session_tokens und private_uploads.

Aktualisieren Sie nun das assets-Array in security-model.json. Der folgende Befehl verwendet ein Python-Here-Document. Ein Here-Document sendet die Zeilen zwischen den PY-Markern als kurzes Skript an python3:

python3 - <<'PY'
import json
from pathlib import Path

path = Path("security-model.json")
model = json.loads(path.read_text())
model["assets"] = [
    "user_credentials",
    "session_tokens",
    "private_uploads",
    "admin_records",
]
path.write_text(json.dumps(model, indent=2) + "\n")
PY

Überprüfen Sie nur den Assets-Abschnitt:

python3 model-check.py assets

Das erwartete Ergebnis ist:

assets: complete

Vertrauensgrenzen abbilden

In diesem Schritt fügen Sie Vertrauensgrenzen (Trust Boundaries) hinzu. Eine Vertrauensgrenze ist ein Bereich, in dem Daten zwischen Zonen mit unterschiedlichem Kontroll- oder Vertrauensniveau übertragen werden. Grenzen sind nützlich, da viele Angriffe stattfinden, wenn nicht vertrauenswürdige Eingaben in vertrauenswürdigen Code, Dateien oder privilegierte Funktionen gelangen.

Betrachten Sie erneut die Routenliste:

python3 app.py routes

Die Routen /login, /files und /download empfangen Eingaben von der Benutzerseite und leiten sie an die Serverlogik weiter. Das ist die Grenze browser_to_server in diesem kleinen Modell.

Die Route /download liest Namen aus der Anfrage und greift dann auf das Verzeichnis uploads zu. Das erzeugt eine server_to_filesystem-Grenze. Die Route /admin trennt normale Benutzer von Daten, die nur Administratoren zugänglich sind, und schafft somit eine user_to_admin_area-Grenze.

Fügen Sie diese Grenzen dem Modell hinzu:

python3 - <<'PY'
import json
from pathlib import Path

path = Path("security-model.json")
model = json.loads(path.read_text())
model["trust_boundaries"] = [
    "browser_to_server",
    "server_to_filesystem",
    "user_to_admin_area",
]
path.write_text(json.dumps(model, indent=2) + "\n")
PY

Überprüfen Sie den Abschnitt für Vertrauensgrenzen:

python3 model-check.py trust_boundaries

Das erwartete Ergebnis ist:

trust_boundaries: complete

Angriffsvektoren hinzufügen

In diesem Schritt fügen Sie Angriffsvektoren (Attack Paths) hinzu. Ein Angriffsvektor ist ein konkreter Weg, auf dem ein Angreifer von einem Einstiegspunkt zu einem Asset gelangen könnte. Dies ist der Kern des Threat Modeling: die Verknüpfung von Assets und Grenzen mit realistischem Angreiferverhalten.

Versuchen Sie einen Login-Versuch mit den Demo-Anmeldedaten:

python3 app.py login alice wonderland

Die Ausgabe ist ein Sitzungs-Token:

session-alice-demo

Dieses Verhalten zeigt, warum Passwörter und Sitzungs-Token wichtig sind. Ein schwaches Passwort könnte credential_guessing ermöglichen, und ein gestohlenes Token könnte zu session_token_theft führen.

Die Route /download akzeptiert einen angeforderten Dateinamen, daher könnte eine nachlässige Implementierung path_traversal ermöglichen. Die Route /admin schützt Administratordatensätze, daher könnten fehlende Rollenprüfungen admin_area_abuse ermöglichen.

Fügen Sie diese Angriffsvektoren dem Modell hinzu:

python3 - <<'PY'
import json
from pathlib import Path

path = Path("security-model.json")
model = json.loads(path.read_text())
model["attack_paths"] = [
    "credential_guessing",
    "session_token_theft",
    "path_traversal",
    "admin_area_abuse",
]
path.write_text(json.dumps(model, indent=2) + "\n")
PY

Überprüfen Sie den Abschnitt für Angriffsvektoren:

python3 model-check.py attack_paths

Das erwartete Ergebnis ist:

attack_paths: complete

Gegenmaßnahmen wählen

In diesem Schritt vervollständigen Sie das Modell, indem Sie Gegenmaßnahmen (Mitigations) hinzufügen. Eine Gegenmaßnahme ist eine Kontrolle, die die Wahrscheinlichkeit oder die Auswirkungen eines Angriffsvektors reduziert. Gute Bedrohungsmodelle verknüpfen jeden wichtigen Angriffsvektor mit mindestens einer praktischen Kontrollmaßnahme.

Verwenden Sie diese Zuordnungen für den kleinen Login-Dienst:

  • credential_guessing kann durch rate_limit_login reduziert werden.
  • session_token_theft kann durch protect_session_tokens reduziert werden.
  • path_traversal kann durch validate_download_paths reduziert werden.
  • admin_area_abuse kann durch enforce_admin_authorization reduziert werden.

Fügen Sie die Gegenmaßnahmen dem Modell hinzu:

python3 - <<'PY'
import json
from pathlib import Path

path = Path("security-model.json")
model = json.loads(path.read_text())
model["mitigations"] = [
    "rate_limit_login",
    "protect_session_tokens",
    "validate_download_paths",
    "enforce_admin_authorization",
]
path.write_text(json.dumps(model, indent=2) + "\n")
PY

Führen Sie nun die vollständige Modellprüfung durch:

python3 model-check.py all

Jeder Abschnitt sollte vollständig sein:

assets: complete
trust_boundaries: complete
attack_paths: complete
mitigations: complete

Sie können sich auch das fertige strukturierte Modell ansehen:

cat security-model.json

Das wichtige Ergebnis ist, dass das Modell nun geschützte Assets, Vertrauensgrenzen, Angriffsvektoren und Gegenmaßnahmen für denselben kleinen Dienst miteinander verbindet.

Zusammenfassung

Sie haben einen praktischen Workflow für das Threat Modeling an einem kleinen Login-Dienst geübt. Sie haben den Dienst untersucht, Assets identifiziert, Vertrauensgrenzen abgebildet, Angriffsvektoren hinzugefügt und diese Pfade in einem strukturierten JSON-Modell mit Gegenmaßnahmen verknüpft.

Dieser Workflow hilft dabei, Sicherheitsüberlegungen direkt mit dem beobachtbaren Systemverhalten zu verbinden, anstatt Threat Modeling als einen separaten, statischen Bericht zu behandeln.