Prüfung zum Registered Information Security Specialist – Frühjahr 2024 (Reiwa 6), Nachmittag, Aufgabe 1 erklärt – JWT alg=none, API-Autorisierung und vorläufige WAF-Abwehr

Wir prüfen das JWT, und trotzdem lässt sich jemand anderes vortäuschen. Das JWT ist völlig gültig, und trotzdem lassen sich fremde Informationen lesen. Die beiden klingen ähnlich, werden aber an unterschiedlichen Stellen behoben. Das Erste ist ein Problem der Tokenprüfung, das Zweite ein Problem der Autorisierung über die Zieldaten.

Aufgabe 1 der Nachmittagssitzung der Prüfung zum Registered Information Security Specialist, Frühjahr 2024 (Reiwa 6), nimmt eine von einem Smartphone aufgerufene API zum Gegenstand und verlangt, diese unterschiedlichen Prüfungen auseinanderzuhalten. Die erste Hälfte behandelt JWT, Benutzer-ID, aktualisierbare Felder und den Authentifizierungscode; die zweite Hälfte eine Bibliotheksschwachstelle und eine WAF.¹

Dieser Artikel stützt sich auf die offiziellen Musterlösungen und den Auswertungskommentar und arbeitet jedes Stück in der Reihenfolge Kern der Antwort, dann die Belege im Aufgabentext, dann der Entwurf, den Sie in der Praxis hinzufügen ab. Lesen Sie ihn so, dass Sie das, was innerhalb der Zeichenvorgabe der Prüfung zu schreiben ist, nicht mit dem verwechseln, was ein reales System tatsächlich braucht.²³

1. Zuerst das Fazit — eine bestandene Prüfung erlaubt nicht, die nächste auszulassen

Das Prinzip, das diesen Artikel durchzieht, lautet: Behandeln Sie den Erfolg der vorherigen Prüfung nie als Grund, die nächste Vertrauensgrenze auszulassen. Eine Vertrauensgrenze ist die Linie, die festlegt, unter welchen Bedingungen ein von außen kommender Wert vertraut werden darf.

Ein gültiges JWT zu besitzen heißt nicht, fremde Informationen lesen zu dürfen. Die eigenen Informationen aktualisieren zu können heißt nicht, auch den Zahlstatus ändern zu dürfen. Ablauf des Authentifizierungscodes und WAF verlangen jeweils eigene Prüfungen und eigene Betriebspraktiken.

Übersicht der Antworten

Die folgende Tabelle gibt die Kernpunkte der offiziellen Antworten. Für die textlichen Antworten prüfen Sie Zeichenzahl und Belege jeder Teilaufgabe in dem zugehörigen Kapitel.²

Beginnen Sie mit Kapitel 2 für den Aufbau der Aufgabe, und lesen Sie die Kapitel 3 bis 10 in der Reihenfolge der Teilaufgaben, um das Ganze zu verfolgen. Wie die Antworten zu schreiben sind, steht in Kapitel 12, die Checkliste für Entwurf und Code-Review in der Praxis in Kapitel 13.

In der Abbildung kennzeichnet eine durchgezogene Linie eine stets geltende Beziehung und eine gestrichelte Linie eine bedingte (die Bedingungen stehen bei jeder Beziehung auf der Detailseite). Die vollständige Liste der Beziehungen (18 insgesamt, mit Beleg und Sicherheitsgrad) und die Definitionen der wichtigsten Konzepte sind auf der Detailseite der Wissenskarte (auf Japanisch) zusammengestellt. Daten: JSON-LD / Turtle

2. Aufbau der Aufgabe — fünf Prüfungen getrennt lesen

Schauplatz ist das Unternehmen G, das einen neuen Gesundheitsdienst anbieten will. Nutzerinnen und Nutzer geben über eine Smartphone-App Mahlzeiten, Gewicht und Ähnliches ein und erhalten eine Einschätzung des Gesundheitsrisikos sowie Hinweise zum Speiseplan. Das System ist in der Cloud aufgebaut und kombiniert API-Gateway, ereignisgetriebene Verarbeitung und eine verwaltete Datenbank.

Produkt- und Dienstnamen im Aufgabentext sind abstrahiert. Dieser Artikel übernimmt die Abbildungen und Tabellen des Aufgabenhefts nicht unverändert, sondern beschreibt die Struktur, die zum Verständnis der Teilaufgaben nötig ist. Stellen, die den Kern der offiziellen Antworten wiedergeben, werden von den hier ergänzten praktischen Hinweisen getrennt.¹

flowchart TB
    accTitle: Überblick über die Aufgabe
    accDescr: Authentifizierungscode, JWT, Ziel-ID, aktualisierte Felder und Ausführung aus externer Eingabe jeweils als eigene Prüfung lesen.
    A["Anfrage der nutzenden Person"] --> B["Abgleich des Authentifizierungscodes"]
    B --> C["Ausstellung und Prüfung des JWT"]
    C --> D["Nutzer-API"]
    D --> E["Autorisierung der Ziel-mid"]
    D --> F["Autorisierung des update-status"]
    D -.-> G["Externe Eingabe ins Protokoll schreiben"]
    G --> H["Verletzliche Bibliothek"]
    H --> I["Externe Codeausführung über JNDI"]

Abbildung 1: Von der Authentifizierung über die API-Operationen bis zur Protokollverarbeitung gibt es mehr als eine Stelle, an der einem Wert vertraut wird.

2.1. Authentifizierung, Tokenprüfung und zwei Arten der Autorisierung trennen

Auch nachdem der Authentifizierungscode die Person bestätigt und das JWT ausgestellt und geprüft wurde, bleibt die Autorisierung über Daten und über einzelne Felder. Der Pfad, der externe Eingabe ins Protokoll schreibt, braucht ebenfalls eine Grenze, die verhindert, dass Eingabe als Befehl behandelt wird.

[Benutzer-ID und Passwort]
          |
          v
[Prüfung des 4-stelligen Codes] ---- ohne Versuchslimit ----> Brute-Force
          |
          v
[JWT ausstellen]
          |
          v
[JWT-Bibliothek] ------- lässt alg=none zu ------> Verfälschung der Benutzer-ID
          |
          v
[Nutzer-API]
    |             |
    |             +-- reicht status unverändert weiter -----> Lücke der Autorisierung auf Eigenschaftsebene
    |
    +-- vertraut mid --------------------------------------> Lücke der Autorisierung auf Objektebene

[Externe Eingabe ins Protokoll schreiben]
          |
          v
[Verletzliche Bibliothek] ---- JNDI/LDAP/HTTP ------> externe Codeausführung

Am wichtigsten ist hier die folgende Unterscheidung.

Dass die vorherige Prüfung gelungen ist, ist kein Grund, die nächste auszulassen. Auch wer ein gültiges JWT besitzt, darf deshalb nicht fremde Daten lesen. Auch wer die eigenen Daten aktualisieren kann, darf deshalb nicht den Zahlstatus ändern.

Können Sie diese Stufen trennen, ist die Antwort zu jeder Teilaufgabe kein Auswendiglernen mehr.

flowchart TB
    accTitle: Unterschied zwischen Authentifizierung und Autorisierung
    accDescr: Die Bestätigung des Subjekts ist eine Sache, und die Prüfung, ob dieses Subjekt Zieldaten oder ein Feld bedienen darf, ist eine eigene Prüfung.
    A["Authentifizierung und Tokenprüfung"] --> B["Feststellen, wessen Anfrage das ist"]
    B --> C["Darf sie diese Daten erreichen"]
    C --> D["Darf sie dieses Feld ändern"]

Abbildung 2: Unterschied zwischen Authentifizierung und Autorisierung. Die Authentifizierung kommt zuerst, die Autorisierung ist eine eigene Prüfung.

2.2. Die Teile von Teilaufgabe 2 am vom Angreifer geänderten Wert unterscheiden

Die in Teilaufgabe 2 leicht zu verwechselnden Punkte ordnen sich, sobald Sie den vom Angreifer kontrollierten Wert betrachten.

Wichtig ist, dass Sie das nicht alles unter Eingabewerte prüfen zusammenwerfen.

• alg ist eine Richtlinie der kryptografischen Verarbeitung
• mid ist Autorisierung auf Objektebene
• status ist Autorisierung auf Eigenschaftsebene
• otp ist Widerstand gegen Online-Raten

Obwohl sie in derselben HTTP-Anfrage sitzen, ist der Grund, sie zu schützen, jeweils ein anderer.

3. Teilaufgabe 1 — zustandslos hält trotzdem Geschäftsdaten und Fehlerzahlen

Teilaufgabe 1 fragt nach einem Entwurfsprinzip von RESTful APIs: der Eigenschaft, keine Sitzungsverwaltung zu betreiben.

Antwort: Lücke a ist zustandslos.²

3.1. Der Beleg — jede Anfrage trägt allein alles, was zur Verarbeitung nötig ist

Zustandslos heißt, dass jede Anfrage für sich die zur Verarbeitung nötigen Informationen trägt, sodass der Server sich den Gesprächszustand der vorherigen Anfrage nicht merken muss. In dieser Aufgabe hängt die Smartphone-App an jede Anfrage ein JWT im Authorization-Header. Der Server prüft dieses JWT und identifiziert die nutzende Person für diese Anfrage.

3.2. Leicht falsch gelesen — es heißt nicht, Daten oder Fehlerzahlen wegzuwerfen

Der leichte Fehler ist, zustandslos als der Server hält gar keinen Zustand zu lesen. Tatsächlich hält er ganz normal Folgendes.

• Die Datenbank mit Nutzerinformationen und Gesundheitsdaten
• Den Zahlstatus
• Wert, Ablauf und Fehlerzahl des Authentifizierungscodes
• Den Signaturschlüssel des JWT
• Widerrufsinformationen, falls der Entwurf eine Widerrufsliste verwendet
• Protokolle und Prüfaufzeichnungen

Was er aufgibt, ist, jeden API-Aufruf von serverseitigem Sitzungszustand abhängig zu machen, der nur dazu da ist, ein Gespräch fortzusetzen.

Zustandslos zu sein verbessert die Sicherheit auch nicht automatisch. Das JWT jedes Mal zu senden erleichtert die horizontale Verteilung, aber ist die JWT-Prüfung falsch, breitet sich der Fehler ebenfalls gleichmäßig auf alle Knoten aus. Eine architektonische Eigenschaft und sicherheitstechnische Korrektheit sind getrennt.

flowchart TB
    accTitle: Zustandslos und gespeicherter Zustand
    accDescr: Jede Anfrage ohne Abhängigkeit von der Gesprächshistorie zu verarbeiten speichert trotzdem Zustand wie Geschäftsdaten und Fehlerzahlen.
    A["Anfrage mit JWT"] --> B["Nutzende Person allein aus dieser Anfrage identifizieren"]
    B --> C["Verarbeiten und antworten"]
    D["Nutzerinformationen, Abrechnung, Fehlerzahl"] -.-> C
    C -.-> E["Keine Abhängigkeit vom vorherigen Gespräch"]

Abbildung 3: Die Abhängigkeit vom Gespräch zu entfernen und Geschäfts- sowie Sicherheitszustand zu speichern sind miteinander vereinbar.

4. Teilaufgabe 2(1) — die mittlere Zeit zum Knacken eines 4-stelligen Codes berechnen

Antwort: Lücke b ist 500. Die Einheit ist Sekunden.²

4.1. Der Beleg — Kandidatenraum, Versuchsgeschwindigkeit und Gültigkeitsdauer zusammenstellen

Stimmt Benutzer-ID und Passwort, sendet die Authentifizierungs-API eine vierstellige Zahl per E-Mail. Stimmen anschließend Benutzer-ID und vierstelliger Code überein, wird ein JWT ausgestellt. Der Code ist ab Erzeugung 10 Minuten gültig.

In der Diagnose waren 10 Versuche pro Sekunde möglich. Gefragt ist, in wie vielen Sekunden der Code im Mittel geknackt wird.

Die Rechnung verwendet die Hälfte des Kandidatenraums

Eine vierstellige Zahl einschließlich führender Nullen hat die folgenden 10.000 Möglichkeiten.

0000, 0001, 0002, ... , 9999

Wird der korrekte Wert gleichmäßig gewählt und ohne Wiederholung der Reihe nach versucht, rechnet die Prüfung die mittlere Versuchszahl als Hälfte des Kandidatenraums.

Mittlere Versuche = 10.000 / 2 = 5.000 Versuche
Mittlere Zeit     = 5.000 / 10 Versuche pro Sekunde = 500 Sekunden

Diese Näherung ergibt die offizielle Antwort von 500 Sekunden. Streng über die Versuche 1 bis 10.000 gemittelt wären es 5.000,5 Versuche; hier folgen wir der Prüfungsantwort.

Im Höchstfall dauert es 1.000 Sekunden, aber die Aufgabe fragt nach dem Mittel. Und die Gültigkeitsdauer des Codes beträgt 600 Sekunden, länger als die mittleren 500 Sekunden zum Knacken. Deshalb wurde beurteilt, dass er mit hoher Wahrscheinlichkeit geknackt wird.

flowchart TB
    accTitle: Zeitgefühl beim 4-stelligen Authentifizierungscode
    accDescr: In der Prüfungsnäherung sind es im Mittel 500 Sekunden, und ohne Wiederholung lassen sich in 600 Sekunden Gültigkeit 60 Prozent der Kandidaten prüfen.
    A["Kandidatenraum 10000"] --> B["Im Mittel etwa 5000 Versuche"]
    B --> C["Bei 10 pro Sekunde etwa 500 Sekunden"]
    C --> D["Kürzer als 600 Sekunden Gültigkeit"]
    D -.-> E["In 600 Sekunden 6000 Kandidaten"]

Abbildung 4: Zeitgefühl beim 4-stelligen Authentifizierungscode. Die Hälfte der Kandidaten im Mittel zu versuchen trifft innerhalb der Gültigkeit.

4.2. Praktischer Hinweis — nicht nur die Ablaufzeit, sondern die mögliche Versuchszahl betrachten

Die Stärke eines Authentifizierungscodes ergibt sich weder allein aus der Stellenzahl noch allein aus der Gültigkeitsdauer.

Versuche innerhalb der Gültigkeit
= Versuche pro Sekunde × Gültigkeitsdauer
= 10 × 600
= 6.000 Versuche

Ohne Wiederholung der Reihe nach lassen sich 60 Prozent von 10.000 innerhalb der Gültigkeit prüfen. Eine Ablaufzeit allein reicht nicht, wenn die Versuchszahl unbegrenzt ist.

Die geltende NIST SP 800-63B verlangt für kurzlebige Geheimnisse in der Out-of-Band-Authentifizierung mindestens 6 Stellen und macht unter 64 Bit eine Begrenzung der Versuchszahl verpflichtend. Außerdem verlangt sie, E-Mail nicht als Out-of-Band-Authentifizierung zu verwenden⁴. In der Prüfung antworten Sie innerhalb der gegebenen Spezifikation von 4 Stellen und E-Mail-Versand; in einem neuen praktischen Entwurf sollten Sie diese Voraussetzungen selbst prüfen.

5. Teilaufgabe 2(2) — dem Angreifer nicht die JWT-Prüfmethode wählen lassen

Kern der Antwort

Die Teilaufgabe fragt, gegen welche Daten die korrigierte Bibliothek Q welche Prüfung durchführt, jeweils in höchstens 20 Zeichen.

Die Musterlösung lautet wie folgt.

Das ist die unmittelbare Korrektur der im Aufgabentext beschriebenen Schwachstelle.² Nur die Signatur prüfen zu antworten wiederholt eine bereits vorhandene Verarbeitung. Der Auswertungskommentar nennt genau solche Fehlantworten.³

5.1. Der Beleg — die vorhandene Signaturprüfung wählt falsch

Das JWT der Aufgabe besteht aus Header, Payload und Signatur.

base64url(header).base64url(payload).base64url(signature)

Im Header war als Signaturalgorithmus RS256 verzeichnet. In der Payload stehen Benutzer-ID, Ausgabezeit und Ablauf.

Die diagnostizierende Person änderte zwei Dinge.

1. alg im Header von RS256 nach NONE
2. Die Benutzer-ID in der Payload zu einer anderen Person

Dieses JWT gesendet, gelang die Prüfung, und es ließ sich jemand anderes vortäuschen.

flowchart TB
    accTitle: Ablauf des JWT-alg=none-Angriffs
    accDescr: Ändert der Angreifer Prüfmethode und Benutzer-ID, nimmt eine Bibliothek, die none zulässt, das verfälschte JWT an.
    A["Gültiges JWT beschaffen"] --> B["alg auf none setzen"]
    B --> C["user auf eine andere Person setzen"]
    C --> D["Bibliothek überspringt die Signaturprüfung"]
    D --> E["Als andere Person angenommen"]

Abbildung 5: Ablauf des JWT-alg=none-Angriffs. Der Angreifer wählt den Prüfalgorithmus.

none ist kein Wert, den die Spezifikation auslässt

RFC 7519 definiert ein JWT ohne Signatur und ohne Verschlüsselung, dessen alg none ist, als Unsecured JWT⁵. Der Wert none existiert also in der Spezifikation.

Das Problem ist, dass eine API, die nur signierte JWTs annehmen sollte, das vom Angreifer angegebene none angenommen hat.

Die verletzliche Verarbeitung sieht begrifflich so aus.

1. JWT-Header lesen
2. Am im Header stehenden alg die Prüfmethode wählen
3. Ist alg none, die Signatur nicht prüfen
4. Der Benutzer-ID in der Payload vertrauen

Aus einer vom Angreifer kontrollierten Eingabe wird die Stärke der Sicherheit selbst gewählt.

5.2. Praktischer Hinweis — erlaubte Algorithmen serverseitig festlegen

Hier müssen Prüfungsantwort und praktische Empfehlung getrennt werden.

RFC 8725 verlangt, dass eine JWT-Bibliothek die Menge erlaubter Algorithmen von der aufrufenden Seite vorgegeben bekommt und keine anderen verwendet⁶. Also so:

Schlechte Idee:
  annehmen, wenn token.header.alg != "none"

Gute Idee:
  nur annehmen, wenn in serverConfig.allowedAlgorithms enthalten
  Beispiel: allowedAlgorithms = ["RS256"]

Nur none abzulehnen lässt schwache Algorithmen und die Verwechslung von Public-Key- und Shared-Key-Verfahren übrig. Die Annahme nicht durch Verneinungen zu erweitern, sondern die erlaubten Bedingungen eng festzulegen, ist der Grundsatz.

Bei der JWT-Prüfung prüfen Sie neben dem Algorithmus je nach Verwendung mindestens Folgendes.

In dieser Aufgabe heißt der Payload-Schlüssel user; in der Praxis verwenden Sie das übliche sub oder definieren die Bedeutung eines eigenen Claims klar.

flowchart TB
    accTitle: Sichere und unsichere JWT-Prüfung
    accDescr: Die Prüfmethode nicht aus der Angabe des Tokens wählen, sondern Signatur und Claims prüfen, nachdem die serverseitigen Erlaubnisbedingungen erfüllt sind.
    A["JWT empfangen"] --> B{"Erlaubter Server-alg?"}
    B -->|"Nein"| X["Ablehnen"]
    B -->|"Ja"| C["Signatur und Claims prüfen"]
    C --> D["Als geprüftes Subjekt behandeln"]
    Y["Unsichere Verarbeitung"] -.-> Z["Prüfung wegen angegebenem none überspringen"]

Abbildung 6: Sichere und unsichere Prüfung. In der Praxis legen Sie die erlaubten Algorithmen eng fest.

5.3. Signatur und Geheimhaltung trennen — base64url ist keine Verschlüsselung

Ein weiteres Missverständnis bei JWT: Header und Payload sind in base64url dargestellt, aber das ist keine Verschlüsselung. Jede Person kann sie decodieren und lesen.

Die Signatur garantiert nur, dass der Inhalt nach der Ausstellung nicht verändert wurde, sofern sie korrekt geprüft wurde. Das heißt nicht, dass schutzbedürftige personenbezogene Daten in die Payload eines signierten JWT dürfen.

flowchart TB
    accTitle: JWT-Signatur und Geheimhaltung sind getrennt
    accDescr: base64url ist eine auch für Dritte lesbare Darstellung; Erkennung von Verfälschung durch die Signatur und Vertraulichkeit sind getrennt zu denken.
    A["Signiertes JWT"] --> B["Header und Payload lesen"]
    B --> C["base64url decodieren"]
    C --> D["Inhalt wird nicht geheim"]
    A --> E["Signatur korrekt prüfen"]
    E --> F["Prüfen, ob unverändert"]

Abbildung 7: Die Signatur dient der Erkennung von Verfälschung, nicht dazu, den Inhalt unlesbar zu machen.

6. Teilaufgabe 2(3) — ein gültiges JWT und ein gültiges Ziel sind getrennt

Kern der Antwort

Unterstreichung 2 in Tabelle 5 fragt in höchstens 40 Zeichen nach der Verarbeitung, die in die Aufrufverarbeitung des gemeinsamen Moduls P einzufügen ist.

Die Musterlösung lautet:²

Verarbeitung, die prüft, ob die im JWT enthaltene Benutzer-ID mit dem Wert von mid übereinstimmt

Die im Aufgabentext vorgeschriebene Einfügestelle ist nicht das gemeinsame Modul P selbst, sondern die P-Aufrufverarbeitung, die P aufruft. Dort fügen Sie den Abgleich von JWT und mid hinzu.¹

In der Praxis ist das Ziel, die Autorisierung einschließlich der Seite von P in der gemeinsamen Schicht, die Daten erreicht, durchgängig durchzuführen. Dann wirkt dieselbe Autorisierung auf GET und PUT und auf künftige APIs, die P nutzen. Vergleichslogik in jeden Bildschirm oder Endpunkt zu kopieren führt zu Auslassungen.

6.1. Der Beleg — Subjekt des JWT und Ziel-mid kommen getrennt an

Dies ist ein Angriff, der das JWT selbst nicht verfälscht.

Die Nutzer-API nimmt per GET oder PUT eine Benutzer-ID namens mid entgegen. Das gemeinsame Modul P holt und aktualisiert die an diese mid gebundenen Nutzerinformationen aus der Datenbank.

Das Angriffsmuster ist einfach.

Benutzer-ID im JWT: user01    ← korrekt signiertes JWT
mid der Anfrage: user02       ← vom Angreifer geändert

Die JWT-Signatur ist korrekt, die Authentifizierung gelingt. Die API vertraut jedoch mid=user02 und gibt die Informationen von user02 zurück.

Das ist ein typischer Fall von Broken Object Level Authorization (BOLA) in der OWASP API Security Top 10 2023. Wenn über eine vom Nutzer angegebene Objekt-ID auf Daten zugegriffen wird, muss die Autorisierung für dieses Objekt jedes Mal geprüft werden⁷.

flowchart TB
    accTitle: BOLA-Angriff
    accDescr: Subjekt des gültigen JWT und Anfrage-mid unterscheiden sich, und allein anhand von mid werden fremde Informationen zurückgegeben.
    A["Korrekt signiertes JWT (user01)"] --> C["Nutzer-API"]
    B["Geänderte mid (user02)"] --> C
    C --> D["Kein Abgleich mit dem Subjekt"]
    D --> E["Daten von user02 holen und aktualisieren"]

Abbildung 8: BOLA-Angriff. Die Authentifizierung gelingt, die Autorisierung wird nicht geprüft.

6.2. Praktischer Hinweis — eine nur für die eigene Person bestimmte API sollte mid nicht annehmen

Eine API, die nur die eigenen Informationen holt und aktualisiert, braucht keine Benutzer-ID vom Client.

GET /users/me
Authorization: Bearer <JWT>

Serverseitig entnehmen Sie das Subjekt dem geprüften JWT.

principal = validateJwt(request.authorization)
userId = principal.subject
return repository.getUser(userId)

Aktualisieren ebenso.

principal = validateJwt(request.authorization)
input = validateProfileUpdate(request.body)
repository.updateProfile(
    userId = principal.subject,
    name = input.name,
    age = input.age
)

Eine Vergleichsverarbeitung schützt, wenn sie geschrieben ist. Nimmt der Entwurf die Ziel-ID gar nicht von außen entgegen, verringert sich die Sorte von Fehlern, die Vergleichsverarbeitung zu vergessen.

Muss eine Administration fremde Nutzerinformationen bedienen, trennen Sie so.

PUT /users/me                  für gewöhnliche Nutzerinnen und Nutzer
PUT /admin/users/{userId}      für Administration

Für die Administration verlangen Sie andere Rechte, Prüfprotokolle und bei Bedarf erneute Authentifizierung. Das macht die Grenze der Autorisierungsrichtlinie sichtbarer als eine Ausnahme nur für den Administrationsfall in der allgemeinen API.

flowchart TB
    accTitle: BOLA verhindern
    accDescr: Übereinstimmung von geprüftem Subjekt und mid prüfen oder in einer nur für die eigene Person bestimmten API das Ziel aus dem Subjekt ableiten, um Vergleichsauslassungen zu verringern.
    A["Subjekt des geprüften JWT"] --> B{"Wie die Ziel-ID bestimmt wird"}
    B -->|"mid entgegennehmen"| C{"Stimmt mit dem Subjekt überein?"}
    C -->|"Ja"| D["Eigene Daten bedienen"]
    C -->|"Nein"| E["Ablehnen"]
    B -->|"Nur-eigene API"| F["Ziel-ID aus dem Subjekt ableiten"]
    F --> D

Abbildung 9: BOLA verhindern. mid nicht entgegennehmen oder mit dem Subjekt des JWT abgleichen.

6.3. Zur Erinnerung — wer Sie sind und was Sie tun dürfen sind getrennt

In Prüfung und Praxis hilft die folgende Formulierung.

• Authentifizierung: wer Sie sind
• Autorisierung: was diese Person tun darf

Dass die JWT-Signaturprüfung gelungen ist, reicht bis dahin, diesem Token als Subjekt zu vertrauen. Dass dieses Subjekt user02 lesen darf, muss getrennt geprüft werden.

7. Teilaufgabe 2(4) — nur Felder annehmen, die aktualisiert werden dürfen

Antwort: Lücke c ist gemeinsames Modul P.²

7.1. Der Beleg — wohin das spezifikationsfremde status gereicht wurde

In der Spezifikation der Nutzer-API sind als Aktualisierungsparameter definiert:

mid   Benutzer-ID
name  Name
age   Alter

Die diagnostizierende Person fügte jedoch den nicht spezifizierten Wert hinzu:

status=paid

Daraufhin wurde der Status einer kostenlosen nutzenden Person zu einer zahlenden.

Laut Aufgabentext prüfte Dienst L die empfangenen Parameter nicht und reichte alle an das gemeinsame Modul P weiter. P konnte die Datenbank unverändert aktualisieren.

Die Stelle, die spezifikationsfremde Werte entgegennimmt und bis zum Nutzerstatus aktualisieren kann, ist also das gemeinsame Modul P.

flowchart TB
    accTitle: Mass Assignment
    accDescr: Wird auch spezifikationsfremdes status an das gemeinsame Modul weitergereicht und aktualisiert, kann die nutzende Person den Zahlstatus ändern.
    A["Spezifikation ist mid, name, age"] --> B["status=paid hinzufügen"]
    B --> C["Alle Parameter an P reichen"]
    C --> D["Unverändert ins interne Datenobjekt übernehmen"]
    D --> E["Zahlstatus wird paid"]

Abbildung 10: Mass Assignment. Eine spezifikationsfremde Eigenschaft wird unverändert ins interne Objekt übernommen.

7.2. Unterschied zu BOLA — nicht das Ziel, sondern die Felder darin schützen

Das Vertauschen von mid im vorigen Kapitel und das Hinzufügen von status ähneln sich, die zu schützende Körnung unterscheidet sich.

Die OWASP API Security Top 10 2023 behandelt Letzteres als Broken Object Property Level Authorization und ordnet das frühere Mass Assignment dieser Klasse zu⁸.

7.3. Praktischer Hinweis — den Eingabetyp für Aktualisierungen zur Positivliste machen

Eine verletzliche Implementierung sieht begrifflich so aus.

entity = repository.find(body.mid)
bindAllProperties(entity, body)
repository.save(entity)

Auch wenn die Oberfläche nur Eingabefelder für name und age hat, kann ein Angreifer die HTTP-Anfrage direkt erzeugen. Was in der UI fehlt, ist keine Sicherheitsgrenze.

Eine sichere Implementierung macht die aktualisierbaren Felder ausdrücklich.

input = parseExactSchema(body, fields = ["name", "age"])

entity = repository.find(authenticatedUserId)
entity.name = input.name
entity.age  = input.age
repository.save(entity)

Wichtig sind zwei Punkte.

1. Im Eingabetyp für Aktualisierungen nur Felder legen, die die nutzende Person ändern darf
2. Spezifikationsfremde unbekannte Felder nicht ignorieren, sondern möglichst als Fehler ablehnen

Unbekannte Felder still zu ignorieren verdeckt, dass ein Angriff gescheitert ist, und übergeht Implementierungsfehler des Clients und Anzeichen von Angriffen. Gibt es keinen Kompatibilitätsgrund, lässt sich mit einem strengen Schema leichter untersuchen.

flowchart TB
    accTitle: Autorisierung auf Feldebene
    accDescr: Den Eingabetyp für Aktualisierungen auf name und age beschränken und den Zahlstatus über einen eigenen Pfad aus geprüften Zahlungsbenachrichtigungen aktualisieren.
    A["Anfrage zur Profilaktualisierung"] --> B{"Nur name und age?"}
    B -->|"Ja"| C["Nur erlaubte Felder aktualisieren"]
    B -->|"Nein"| D["Unbekannte Felder ablehnen"]
    E["Geprüfte Zahlungsbenachrichtigung"] --> F["paymentId abgleichen und Doppelverarbeitung verhindern"]
    F --> G["status über eigenen Pfad aktualisieren"]

Abbildung 11: Autorisierung auf Feldebene. Aktualisierbare Felder per Positivliste beschränken und den Zahlstatus auf einem anderen Pfad ändern.

7.4. Den Zahlstatus nur aus einem geprüften Zahlungsergebnis ändern

status=paid ist kein Teil des Nutzerprofils. Es ist ein Zustand, der aus der serverseitigen Tatsache folgt, dass eine Zahlung gelungen ist.

Aktualisierung des Nutzerprofils
  -> nur name / age änderbar

Geprüfte Benachrichtigung vom Zahlungsdienst
  -> paymentId abgleichen
  -> Doppelverarbeitung verhindern
  -> status auf paid setzen

Auch wenn sie in derselben Datenbankspalte liegen, sind Berechtigung und Pfad der Änderung getrennt. Wird die interne Entität unverändert als Eingabetyp der externen API verwendet, verschwindet diese Grenze.

7.5. Gemeinsame Bausteine sollen Autorisierung und Eingabebeschränkung enthalten

In dieser Aufgabe treten zwei gemeinsame Bausteine auf: die JWT-Verwaltungsbibliothek Q und das gemeinsame Modul P.

Gemeinsame Bausteine haben große Vorteile.

• Eine Stelle zu korrigieren wirkt auf alle nutzenden APIs
• Autorisierung und Prüfung müssen nicht in jeder Funktion wiederholt werden
• Der Testgegenstand lässt sich bündeln
• Form von Protokoll und Prüfung lässt sich vereinheitlichen

Andererseits breitet sich ein Fehler auf das Ganze aus.

• Nimmt Bibliothek Q alg=none an, werden alle APIs, die JWT nutzen, gefährlich
• Nimmt gemeinsames Modul P beliebige mid oder status an, werden GET und PUT gefährlich
• Wird die verletzliche Bibliothek H in der Grundlage verwendet, werden mehrere Pfade, die HTTP-Header protokollieren, zur Angriffsfläche

Gemeinsam zu machen ist also nicht bloßer Datenzugriff. Sicherheitsinvarianten müssen gemeinsam gemacht und dieser gemeinsame Baustein für sich streng geprüft werden.

Zum Beispiel so als Vertrag von P:

P.getOwnUser(authenticatedSubject)
P.updateOwnProfile(authenticatedSubject, ProfileUpdate{name, age})

Niedrige APIs der folgenden Art sollten der allgemeinen aufrufenden Seite nicht unverändert offenstehen.

P.getUser(arbitraryMid)
P.updateUser(arbitraryMap)

Letztere braucht nur begrenzte Pfade wie die Administration. Die Freiheit der niedrigen Schicht an alle APIs zu verteilen ist ein Entwurf, der darauf hofft, dass jede aufrufende Seite sie jedes Mal richtig verwendet.

flowchart TB
    accTitle: Vertrag gemeinsamer Bausteine eng halten
    accDescr: Autorisierung und Eingabetyp in den Vertrag des gemeinsamen Bausteins aufzunehmen verringert die Abhängigkeit davon, dass die aufrufende Seite jedes Mal richtig verwendet.
    A["API für gewöhnliche Nutzerinnen und Nutzer"] --> B["Geprüftes Subjekt und Update-DTO"]
    B --> C["Autorisierung im gemeinsamen Baustein vereinheitlichen"]
    C --> D["Erlaubte Daten bedienen"]
    E["Bedienung beliebiger IDs und Maps"] -.-> F["Auf begrenzte Pfade wie Administration trennen"]
    C -.-> G["Gemeinsamen Baustein streng testen"]

Abbildung 12: Gemeinsam zu machen sind nicht nur der Datenzugriff, sondern die zu schützenden Bedingungen von Autorisierung und Eingabe.

8. Teilaufgabe 2(5) — Fehlversuche zählen und das Brute-Force stoppen

Gegen das Brute-Force des 4-stelligen Codes ist die in Lücke d von Tabelle 5 einzufügende Verarbeitung in höchstens 30 Zeichen zu beantworten. Der Schwellenwert ist 10.

Die Musterlösung lautet:²

Verarbeitung, die das Konto sperrt, sobald die Zahl aufeinanderfolgender Fehlversuche den Schwellenwert überschreitet

8.1. Der Beleg — die Fehlerzahl ist Zustand, den Sicherheitsentscheidungen brauchen

Das widerspricht dem Zustandslos von Teilaufgabe 1 nicht. Keinen Gesprächszustand der API-Aufrufe als Serversitzung zu halten und die für Sicherheitsentscheidungen nötige Fehlerzahl dauerhaft zu speichern sind getrennt.

flowchart TB
    accTitle: Mit und ohne Begrenzung der Versuchszahl
    accDescr: Die Fehlerzahl zu halten und bei Überschreiten des Schwellenwerts zu sperren stoppt unbegrenztes Online-Raten.
    A["Abgleich des Codes fehlgeschlagen"] --> B["Fehlerzahl des Kontos aktualisieren"]
    B --> C{"Schwellenwert überschritten?"}
    C -->|"Ja"| D["Konto sperren"]
    C -->|"Nein"| E["Verbleibende Versuche zulassen"]
    F["Ohne Begrenzung kann weitergeraten werden"] -.-> A

Abbildung 13: Mit und ohne Zahlenbegrenzung. Eine Begrenzung der Fehlversuche stoppt Brute-Force praktisch.

8.2. Praktischer Hinweis — auch auf Aussperren durch Sperren vorbereiten

Eine kontobezogene Zahlenbegrenzung ist nötig, kennt der Angreifer jedoch die Benutzer-ID einer anderen Person, kann er absichtlich bis über den Schwellenwert scheitern und die rechtmäßige Person aussperren. Deshalb kombinieren Sie in der Praxis Folgendes.

Außerdem darf die Fehlerzahl beim erneuten Senden eines Codes nicht auf 0 zurückgesetzt werden. Sonst kann der Angreifer das Versuchskontingent jedes Mal wiederbeleben, wenn er die Sende-API aufruft. Auch die geltende NIST SP 800-63B verlangt, die Fehlerzahl beim Erzeugen eines neuen Authentifizierungsgeheimnisses nicht zurückzusetzen⁴.

8.3. Neuausstellung, Wiederverwendung und Sende-API als ein Satz schützen

Im Aufgabentext steht die Gültigkeitsdauer im Zentrum; in der Praxis brauchen Sie außerdem Folgendes.

• Einen erfolgreichen Code sofort ungültig machen
• Wiederverwendung desselben Codes ablehnen
• Den Code selbst nicht ins Protokoll schreiben
• Antworten so gestalten, dass sich aus Erfolg oder Misserfolg des Abgleichs nicht auf die Existenz der Person schließen lässt
• Auch die API zum Senden des Codes zahlenmäßig begrenzen

Ein kurzes Geheimnis darf seine Sicherheit nicht allein der Zufallserzeugung überlassen.

flowchart TB
    accTitle: Maßnahmen zum Authentifizierungscode
    accDescr: Neben Kandidatenraum und Gültigkeit Fehlerzahl halten, nach Erfolg ungültig machen, benachrichtigen und Wiederherstellung kombinieren.
    A["Code ausstellen und neu ausstellen"] --> B["Fehlerzahl nicht zurücksetzen"]
    B --> C["Mit Begrenzung von Zahl und Geschwindigkeit abgleichen"]
    C --> D{"Abgleich gelungen?"}
    D -->|"Ja"| E["Code sofort ungültig machen"]
    D -->|"Nein"| F["Fehler aufzeichnen, verzögern, sperren"]
    F --> G["Benachrichtigung und sicheres Wiederherstellen"]
    A -.-> H["Auch Sende-API begrenzen, Code nicht aufzeichnen"]

Abbildung 14: Maßnahmen zum Authentifizierungscode. Nicht nur Stellenzahl und Ablauf, sondern Versuchssteuerung und Betrieb kombinieren.

9. Teilaufgabe 3(1) — die Ausführung des Prüfbefehls am Zugriffsprotokoll feststellen

Kern der Antwort

Teilaufgabe 3(1) fragt, was auf dem Testserver zu implementieren ist, um festzustellen, dass der Befehl ausgeführt wurde.

Die Musterlösung lautet:

Eine Einrichtung, die Zugriffe auf index.html des Testservers aufzeichnet und prüft²

9.1. Der Beleg — beobachten, dass die Kette bis zum letzten Prüfbefehl gelangt ist

Nach Betriebsbeginn wird in der weit verbreiteten Open-Source-Bibliothek H die schwerwiegende Schwachstelle V veröffentlicht. Der Ablauf im Aufgabentext ist:

1. Der Angreifer sendet eine Zeichenfolge mit JNDI Lookup in einem HTTP-Header
2. Der angegriffene Server schreibt den Wert ins Protokoll
3. Die verletzliche Bibliothek wertet den JNDI Lookup aus und fragt den Angriffs-LDAP-Server
4. Die LDAP-Antwort liefert die URL des Angriffs-HTTP-Servers
5. Der angegriffene Server holt die Klassendatei und führt den Befehl aus

Das liest sich als Angriff vom Typ Log4Shell (CVE-2021-44228) mit verschwiegenem Eigennamen. Auch Apache beschreibt die Schwachstelle so, dass steuerbare Protokollnachrichten oder Parameter beliebigen von einem LDAP-Server geladenen Code ausführen können⁹.

flowchart TB
    accTitle: Bestätigungsablauf einer Schwachstelle vom Typ Log4Shell
    accDescr: Nicht nur JNDI-Auflösung und Klassenholung, sondern das Holen von index.html durch den Prüfbefehl im Protokoll bestätigen.
    A["Externe Eingabe im HTTP-Header"] --> B["Protokollverarbeitung des Zielservers"]
    B --> C["Über JNDI LDAP abfragen"]
    C --> D["URL der Klassenquelle empfangen"]
    D --> E["Zielserver holt die Klasse"]
    E --> F["Prüfbefehl auf dem Zielserver ausführen"]
    F --> G["index.html des Testservers holen"]
    G --> H["Diesen Zugriff aufzeichnen und prüfen"]

Abbildung 15: Bestätigungsablauf einer Schwachstelle vom Typ Log4Shell. Statt eines zerstörerischen Befehls die Ankunft über die Aufzeichnung eines HTTP-Zugriffs bestätigen.

Der Prüfbefehl bewirkt nur einen harmlosen HTTP-Zugriff

Unternehmen G führt einen das System nicht beeinträchtigenden Prüfcode aus und prüft, ob Schwachstelle V von außen ausnutzbar ist. Der Befehl des Prüfcode holt nur index.html des Testservers.

Bleibt im Zugriffsprotokoll des Webservers ein GET vom angegriffenen Server, lässt sich mindestens die folgende Kette bestätigen.

Externe HTTP-Anfrage
  -> Protokollverarbeitung
  -> JNDI Lookup
  -> LDAP-Antwort
  -> Klassenholung
  -> Ausführung des Prüfbefehls
  -> HTTP-Zugriff auf den Testserver

9.2. Warum das Protokoll des Testservers statt einer Anzeige auf dem Bildschirm

Das Angriffsziel ist der Server. Auf dem Browserbildschirm der nutzenden Person muss sich nichts ändern. Und selbst wenn die Schwachstelle besteht, kann ausgehende Kommunikation unterwegs an einer Firewall enden.

Zeichnet der Testserver Zugriffe auf, ist das ein beobachtbarer Beleg, dass der angegriffene Server nach außen gelangt ist.

9.3. Praktischer Hinweis — mit Genehmigung und kleinster Nebenwirkung feststellen

Führen Sie gleichartige Prüfungen in der Praxis nur unter folgenden Bedingungen durch.

• Ausdrückliche Genehmigung der Eigentümerin oder des Eigentümers des Zielsystems
• Eine Prüfmethode ohne oder mit hinnehmbarer Auswirkung auf den Produktivbetrieb
• Keine zerstörerischen Befehle wie Schreiben, Löschen oder Konfigurationsänderung
• Prüfdomäne und -server selbst verwalten
• Prüfzeit, Quelle, Ziel und erwarteten Callback aufzeichnen
• Temporäre LDAP- und HTTP-Server sowie Zugangsdaten nach der Prüfung entfernen

Feststellen, dass beliebige Codeausführung möglich ist, und beliebigen gefährlichen Code ausführen ist nicht dasselbe. Beschränken Sie sich auf die kleinste Nebenwirkung, die den Zweck erfüllt.

flowchart TB
    accTitle: Prüfung auf die kleinste Nebenwirkung beschränken
    accDescr: Mit Genehmigung harmlose Bestätigung und Beobachtungsbedingungen festlegen und nach der Ausführung Prüfumgebung und Zugangsdaten entfernen.
    A["Ausdrückliche Genehmigung der Eigentümerin oder des Eigentümers"] --> B["Auswirkung und Beobachtungsbedingungen festlegen"]
    B --> C["Zugriff auf einem verwalteten Server aufzeichnen"]
    C --> D["Mit erwarteter Zeit und Quelle abgleichen"]
    D --> E["Prüfumgebung und Zugangsdaten entfernen"]
    B -.-> F["Nicht schreiben, löschen oder Einstellungen ändern"]

Abbildung 16: Zuerst die zu beobachtende Tatsache festlegen und harmlose Bestätigung sowie Aufräumen in das Prüfverfahren aufnehmen.

10. Teilaufgaben 3(2) bis (4) — Prüfziel, Muster und Verhalten der WAF festlegen

10.1. Teilaufgabe 3(2) — beide Prüfziele sind Header

Die WAF von Dienst N kann als Prüfziel GET, POST, PUT, ANY, Header, COOKIE und Multipart wählen.

Der Angriffscode sitzt im Wert des HTTP-Headers x-api-version. Deshalb sind Lücke e und f in Tabelle 6 beide Header.²

Der Beleg ist der Ort, an dem die Angriffszeichenfolge sitzt

Das ist weniger Allgemeinwissen als das Lesen des Datenflusses im Aufgabentext.

Ort der Angriffszeichenfolge:
  Header x-api-version
          |
          v
Prüfziel der WAF:
  Header

ANY in dieser Aufgabe prüft Parameterwerte aller Methoden und ist von Header, das Header prüft, getrennt.¹

Es ist weder ein GET-Parameter noch ein POST-Rumpf. Wählen Sie nicht Angriff, also ANY aus der Funktionsliste, sondern den Ort, an dem der Angreifer im Aufgabentext den Wert eingesetzt hat.

flowchart TB
    accTitle: Prüfziel der WAF wählen
    accDescr: Nicht vom Angriffsnamen, sondern vom im Aufgabentext genannten Speicherort der Angriffszeichenfolge das Prüfziel der WAF festlegen.
    A["Speicherort der Angriffszeichenfolge lesen"] --> B["Header x-api-version"]
    B --> C["Prüfziel ist Header"]
    C --> D["Weiter zum Muster einschließlich Groß- und Kleinschreibung"]
    E["ANY sind Parameter aller Methoden"] -.-> C

Abbildung 17: Nicht vom Angriffsnamen raten, sondern den Speicherort Header dem Prüfziel zuordnen.

10.2. Teilaufgabe 3(3) — für jedes Zeichen Groß- und Kleinschreibung zulassen

Der erste Entwurf war begrifflich die folgende Regel.

Header  \Wjndi\W  sperren
Header  \Wldap\W  sperren

Durch Vertauschen von Groß- und Kleinschreibung wie jNdI lässt sich ein nur kleingeschriebenes Muster umgehen.

Die Musterlösung zu Teilaufgabe 3(3) ist eine der folgenden.²

\W[jJ][nN][dD][iI]\W

\W(j|J)(n|N)(d|D)(i|I)\W

Im Aufgabenheft kann der Backslash in japanischer Umgebung wie das Yen-Zeichen aussehen; als regulärer Ausdruck ist es \W. \W trifft Zeichen außer Buchstaben, Ziffern und Unterstrich. In der Syntax von JNDI Lookup stehen vor und hinter jndi Nicht-Wort-Zeichen wie ${ und :, deshalb werden sie einbezogen.

Dasselbe gilt für ldap.

\W[lL][dD][aA][pP]\W

10.3. Teilaufgabe 3(4) — Erkennung dient dazu, Fehlersperrung zu vermeiden

Zur geänderten WAF-Regel rät RISS-Fachkraft Z, das Verhalten für eine gewisse Zeit nach Produktivstart nicht auf Sperrung, sondern auf Erkennung zu setzen.

Die Teilaufgabe fragt in jeweils höchstens 25 Zeichen nach dem Vorteil der Erkennung und nach dem, was zur Minimierung des Schadens durchzuführen ist.

Die Musterlösung lautet:²

Der Beleg — Erkennung gehört mit dem Prüfen der Alarme zusammen

Im Erkennungsmodus wird übereinstimmender Verkehr durchgelassen, ins Protokoll geschrieben und alarmiert. Steht in einem normalen API-Aufruf zufällig jndi oder ldap, wird der Betrieb nicht sofort gestoppt.

Dafür braucht der Betrieb Folgendes.

Alarm empfangen
   |
   v
Betroffene Anfrage prüfen
   |
   +-- Normalverkehr -> Regel verengen, Ausnahmebedingungen erwägen
   |
   +-- Angriff     -> Ziel isolieren, Protokoll sichern, Auswirkung untersuchen, zur Sperrung

Sieht niemand die Alarme, hat der Erkennungsmodus keine Schutzwirkung. Erkennung ist ein Satz mit einem Betrieb, der beobachtet und entscheidet.

10.4. Praktischer Hinweis — beobachten, anpassen, dann zur Sperrung wechseln

Ein übliches Einführungsverfahren ist:

1. Im Erkennungsmodus auf den echten Verkehr anwenden
2. Fehlalarme und richtige Erkennungen trennen
3. Zielheader, Pfad, API, Zeichengrenzen anpassen
4. Bestätigen, dass die Auswirkung auf normalen Verkehr hinnehmbar ist
5. In den Sperrmodus wechseln
6. Sperrzahl und betriebliche Auswirkung überwachen

Das ist der Grundsatz in ruhigen Zeiten. Ist die Schwachstelle schwerwiegend, wird sie bereits ausgenutzt und gibt es keine Alternative, kann der Schaden durch Kompromittierung größer sein als der Stopp durch Fehlalarme, und Sie sperren von Anfang an. In der Prüfungssituation wird zuerst Erkennung gewählt, um zu prüfen, ob der Dienst weiter wie bisher nutzbar ist.

flowchart TB
    accTitle: Von der WAF-Erkennung zur Sperrung
    accDescr: Alarme während der Erkennung prüfen, Fehlalarme anpassen und Angriffe behandeln, danach auch nach der Sperrung überwachen.
    A["Verkehr im Erkennungsmodus beobachten"] --> B{"Inhalt des Alarms"}
    B -->|"Fehlalarm"| C["Regel oder Ausnahmebedingungen anpassen"]
    C --> A
    B -->|"Angriff"| D["Isolieren, Protokoll sichern, Auswirkung untersuchen"]
    D --> E["Zur Sperrung wechseln"]
    A --> F["Auswirkung auf normalen Verkehr bestätigen"]
    F --> E
    E --> G["Sperrzahl und betriebliche Auswirkung überwachen"]

Abbildung 18: Von der Erkennung zur Sperrung. Zuerst beobachten und anpassen, die Auswirkung als hinnehmbar bestätigen und dann sperren.

11. Schwachstellenbehandlung in der Praxis — mit der WAF Zeit gewinnen, während Aktualisierung und Untersuchung laufen

Im Aufgabentext gab es auf der offiziellen Seite von Bibliothek H noch keine korrigierte Fassung und keine vorläufige Maßnahme, und eine umfassende WAF-Regel des Cloud-Anbieters sollte bis zu 72 Stunden dauern. Deshalb stellt Unternehmen G die Auswirkung selbst fest und wehrt vorläufig wenigstens die bekannten Muster ab.

Was die Prüfung fragt, sind vorläufige WAF-Regeln und ihr Betrieb; die WAF behebt die Schwachstelle selbst nicht. Feststellung der Auswirkung, vorläufige Milderung und grundlegende Korrektur lassen sich dort, wo sie nicht aufeinander warten müssen, parallel vorantreiben. Der Gesamtablauf einschließlich praktischer Ergänzungen ist:

11.1. Die vorläufige Regel nicht für eine vollständige Log4Shell-Abwehr halten

Die Prüfung verlangt den regulären Ausdruck, der der im Text gezeigten Umgehung entspricht. Bei tatsächlichen Angriffen gibt es Aufteilungen der Zeichenfolge, andere Lookups, Kodierung, andere Protokolle, die sich mit Signaturen allein schwer vollständig abdecken lassen.

Die praktische Einordnung ist daher:

1. Jetzt bekannte Angriffsmuster vorläufig mit der WAF stoppen
2. Prüfen, ob die betroffene Bibliothek wirklich enthalten ist
3. Ausgehendes LDAP, RMI und unnötiges HTTP beschränken
4. Auf die korrigierte Fassung aktualisieren
5. Auch nach der Aktualisierung Protokolle prüfen und untersuchen, ob kompromittiert wurde

Die WAF ist die Schicht, die Zeit gewinnt, bis die korrigierte Fassung da ist.

flowchart TB
    accTitle: Einordnung der WAF
    accDescr: Erkennung beobachtet bei durchgelassenem Verkehr; Sperrung und Beschränkung ausgehender Kommunikation mildern, während die Ursache durch Aktualisierung entfernt wird.
    A["Veröffentlichung einer schwerwiegenden Schwachstelle"] --> B["Feststellung der Auswirkung und vorläufige Reaktion"]
    B --> C["Protokoll und Alarme durch Erkennung gewinnen"]
    B --> D["Sperrung und Beschränkung ausgehender Kommunikation"]
    C --> E["Auf Beobachtung gestützt anpassen und behandeln"]
    D --> F["Auf korrigierte Bibliotheksfassung aktualisieren"]
    E --> F
    F --> G["Nachträglich prüfen, ob kompromittiert wurde"]

Abbildung 19: Einordnung der WAF. Die WAF gewinnt Zeit bis zur korrigierten Fassung; die grundlegende Maßnahme ist die Aktualisierung.

11.2. Vorbereitung in ruhigen Zeiten — verwendete Bibliotheken und Einsatzorte kennen

Im Aufgabentext heißt es, selbst wenn Unternehmen G bei F nachfragt, ob Bibliothek H verwendet wird, sei eine ausführliche Konfigurationsanalyse nötig und die Antwort dauere.

In der Praxis verzögert sich die Reaktion, wenn nach Veröffentlichung einer schwerwiegenden Schwachstelle erst mit der Suche nach JAR-Dateien begonnen wird. Mindestens Folgendes sollte in ruhigen Zeiten vorliegen.

• Liste direkter und transitiver Abhängigkeiten
• Tatsächlich in den Lieferungen enthaltene Komponenten und Versionen
• Auf welche Dienste, Container, Geräte sie verteilt sind
• Verfahren, abhängige Bibliotheken zu aktualisieren, neu zu bauen und neu zu verteilen
• Kontaktweg zur Genehmigung dringender Änderungen
• Erlaubte Ziele ausgehender Kommunikation und die Auswirkung, sie zu stoppen
• Speicherort der Protokolle und Suchverfahren

SBOM ist kein Selbstzweck. Sie ist ein Index, um in kurzer Zeit zu beantworten, welche laufenden Systeme diese Schwachstelle betrifft.

flowchart TB
    accTitle: Abhängigkeiten mit laufenden Systemen verknüpfen
    accDescr: Abhängige Komponenten und Verteilungsziele in ruhigen Zeiten zuordnen, damit Untersuchung und Aktualisierungsentscheidung nach Veröffentlichung einer Schwachstelle schneller sind.
    A["Liste direkter und transitiver Abhängigkeiten"] --> B["Tatsächliche Version in der Lieferung"]
    B --> C["Laufende Dienste und Einsatzorte"]
    C --> D["Betroffene in kurzer Zeit entscheiden"]
    D --> E["Genehmigen, neu bauen, neu verteilen"]
    C -.-> F["Auch Kommunikationsziele und Protokollorte kennen"]

Abbildung 20: SBOM zu sammeln ist nicht der Zweck; sie ist ein Index, um Betroffene und Aktualisierungsweg schnell zu entscheiden.

11.3. Nachträgliche Prüfung — die Untersuchung nicht beenden, nur weil aktualisiert wurde

Es ist möglich, dass vor oder nach der Veröffentlichung der Schwachstelle bereits angegriffen wurde. Eine Aktualisierung auf die korrigierte Fassung stoppt künftige Ausnutzung, löscht aber kompromittierte Zugangsdaten oder hinterlegte Hintertüren nicht.

Bei einem Typ Log4Shell untersuchen Sie mindestens:

• HTTP-Anfragen mit verdächtigen Zeichenfolgen, die auf JNDI oder LDAP deuten
• Kommunikation vom Anwendungsserver zu externem LDAP, RMI, HTTP
• Start ungewöhnlicher Kindprozesse
• Erstellung verdächtiger JAR-, class-, Skript- oder ausführbarer Dateien
• Zugriff auf Cloud-Zugangsdaten oder Umgebungsvariablen
• Authentifizierung, Rechteänderungen und externe Sendungen vor und nach der Aktualisierung

Wichtig ist, nicht allein aus WAF-Protokollen zu schließen, dass nicht angegriffen wurde. Es gibt interne Pfade an der WAF vorbei und Protokolle, die aus der Vergangenheit nicht erhalten sind.

flowchart TB
    accTitle: Aktualisierung und Kompromittierungsuntersuchung trennen
    accDescr: Künftige Ausnutzung durch Aktualisierung auf die korrigierte Fassung zu stoppen und zu untersuchen, ob bereits kompromittiert wurde, sind getrennt nötig.
    A["Auf die korrigierte Fassung aktualisieren"] --> B["Künftige Ausnutzung stoppen"]
    C["Aufzeichnungen vor und nach der Aktualisierung untersuchen"] --> D["Kommunikation, Prozesse, Dateien abgleichen"]
    D --> E["Zugangsdaten und externe Sendungen prüfen"]
    B -.-> F["Vergangene Kompromittierung verschwindet nicht"]
    F -.-> C

Abbildung 21: Korrektur der Ursache und Untersuchung bereits eingetretener Kompromittierung getrennt vorantreiben.

12. Antworten schreiben — die Differenz zur Spezifikation in den Begriffen des Aufgabentexts nennen

Diese Aufgabe ist weniger eine Wissensfrage als eine Frage, die Differenz von Spezifikation und Implementierung zu lesen.

12.1 Spezifikation und Implementierung in den Tabellen trennen

Beim status-Problem geht in der Implementierung ein Wert durch, der in der API-Spezifikation nicht steht.

Spezifikation:
  mid / name / age

Implementierung:
  alle empfangenen Parameter an P senden

Ist diese Differenz sichtbar, ist Lücke c das gemeinsame Modul P.

12.2 Unter den vom Angreifer geänderten Wert eine Linie ziehen

Die in den Angriffen geänderten Werte sind:

• alg im JWT-Header
• Benutzer-ID in der JWT-Payload
• mid im API-Parameter
• Spezifikationsfremdes status
• otp der Authentifizierungs-API
• HTTP-Header x-api-version

Die Teilaufgaben fragen fast alle, wo dieser Wert geprüft werden sollte.

12.3 Die Antwort auf die Begriffe des Aufgabentexts zurückführen

In der Praxis können Sie BOLA, Mass Assignment, Rate Limiting sagen. Was die Teilaufgabe verlangt, ist jedoch eine konkrete Verarbeitung, die zum Aufbau des Aufgabentexts passt.

Schlechtes Beispiel:

Die Autorisierung angemessen durchführen.

Gutes Beispiel:

Prüfen, ob die im JWT enthaltene Benutzer-ID mit dem Wert von mid übereinstimmt.

Schlechtes Beispiel:

Brute-Force-Maßnahmen ergreifen.

Gutes Beispiel:

Das Konto sperren, sobald aufeinanderfolgende Fehlversuche den Schwellenwert überschreiten.

Den abstrakten Namen zu kennen reicht nicht für eine in der Zeichenzahl bewertbare Antwort.

12.4 Bei der WAF verfolgen, wo es hineingelangt ist

Das Prüfziel der WAF raten Sie nicht aus der Angriffsart, sondern legen es vom Speicherort der Angriffszeichenfolge fest.

in den Header x-api-version gesetzt
        ↓
Prüfziel ist Header

Im Auswertungskommentar gilt die Gesamtrichtigkeit als durchschnittlich, Teilaufgabe 2(2) und 3(1) als etwas niedriger.³ Die etwas niedrigere Richtigkeit von 3(1) kam daher, dass viele Antworten nicht zum Angriffsablauf in Abbildung 6 passten. Schon die Angriffsfolge in Pfeile umzuschreiben zeigt, was zu beobachten ist.

flowchart TB
    accTitle: Vom Aufgabentext zur Antwort zurück
    accDescr: Differenz von Spezifikation und Implementierung, geänderte Werte und vertraute Verarbeitung verfolgen und die konkrete Verarbeitung in den Begriffen des Aufgabentexts schreiben.
    A["Spezifikation und Implementierung nebeneinanderlegen"] --> B["Geänderten Wert bestimmen"]
    B --> C["Verfolgen, wo vertraut wurde"]
    C --> D["Hinzu zufügende Verarbeitung festlegen"]
    D --> E["Auf Begriffe und Zeichenzahl des Aufgabentexts zurückführen"]

Abbildung 22: Nicht Begriffe auswendig lernen, sondern den Wertefluss verfolgen und als konkrete Verarbeitung antworten.

13. Checkliste für API-Reviews in der Praxis

Eine Checkliste, um diese Aufgabe in tatsächlichen Entwurf und Code-Review mitzunehmen.

JWT-Prüfung

• Der erlaubte Signaturalgorithmus ist in der Serverkonfiguration festgelegt
• none und unerwartete Algorithmen werden abgelehnt
• Signatur, iss, aud, exp, nbf werden je nach Verwendung geprüft
• ID-Token, Access-Token und Refresh-Token werden nicht verwechselt
• Es gibt ein Verfahren für Schlüsselrotation und Widerruf
• In der JWT-Payload stehen keine geheim zu haltenden Informationen

Autorisierung auf Objektebene

• Eine Änderung der ID in der Anfrage erreicht keine fremden Daten
• Autorisiert wird bei Liste, Detail, Aktualisierung, Löschen und Download
• Die Autorisierung erfolgt nicht in der Oberfläche, sondern in der gemeinsamen Schicht, die Daten erreicht
• Bei einer nur für die eigene Person bestimmten API wurde erwogen, die Ziel-ID aus dem Token abzuleiten
• Administrationsoperationen sind von der API für gewöhnliche Nutzerinnen und Nutzer und von deren Richtlinie getrennt

Autorisierung auf Eigenschaftsebene

• Externer Eingabetyp und Datenbankentität sind getrennt
• Aktualisierbare Felder sind auf einer Positivliste aufgezählt
• Spezifikationsfremde Eigenschaften werden abgelehnt oder geprüft
• Zustände wie Rechte, Abrechnung, Freigabe, Eigentum lassen sich nicht aus Nutzereingabe ändern
• Die Antwort enthält keine unnötigen vertraulichen Eigenschaften

Authentifizierungsversuche

• Es gibt eine Begrenzung der Fehlversuche je Konto
• Es gibt gestaffelte Verzögerung oder Steuerung nach Quelle
• Die Fehlerzahl wird bei Neuausstellung des Codes nicht zurückgesetzt
• Der Authentifizierungscode ist nur einmal verwendbar
• Authentifizierungscode und Passwort stehen nicht im Protokoll
• Aufhebung der Sperre und Wiederherstellung sind kein zweiter schwacher Authentifizierungspfad

Schwerwiegende Schwachstellen abhängiger Bibliotheken

• Laufende Dienste und Abhängigkeitsversionen lassen sich zuordnen
• Es gibt ein Verfahren, die Auswirkung auf harmlose Weise zu prüfen
• Vorläufige Maßnahmen wie WAF oder Beschränkung ausgehender Kommunikation lassen sich anwenden
• Es gibt einen Betrieb, in dem Zuständige Erkennungsalarme prüfen
• Es gibt einen Notfall-Release-Pfad zur Aktualisierung auf die korrigierte Fassung
• Die Möglichkeit früherer Ausnutzung wird vor der Aktualisierung in den Protokollen untersucht

flowchart TB
    accTitle: Der Review versucht als Nächstes nach dem Normalfall
    accDescr: Nicht nur den Erfolg der normalen Anfrage, sondern Änderung von ID und Feldern sowie wiederholte Versuche getrennt bestätigen und die Maßnahme der gemeinsamen Schicht prüfen.
    A["Erfolg der normalen Anfrage bestätigen"] --> B["Nur die Ziel-ID ändern und prüfen"]
    B --> C["Unbekanntes Aktualisierungsfeld hinzufügen und prüfen"]
    C --> D["Authentifizierungsfehler und Neuausstellung wiederholen"]
    D --> E["Ablehnung, Aufzeichnung, Wiederherstellung prüfen"]
    E -.-> F["Jeweils als eigene Prüfung behandeln"]

Abbildung 23: Vom Erfolg des Normalfalls ausgehend prüfen, ob die getrennten Grenzen wirklich ablehnen.

14. Zusammenfassung — die nächste Vertrauensgrenze nicht auslassen

Nachmittagsaufgabe 1 im Frühjahr des Reiwa-6-Jahres ist eine Aufgabe, die Punkte der API-Sicherheit einzeln getrennt zu lesen.

Ein JWT zu verwenden bedeutet keine sichere Authentifizierung. Darf der Angreifer den Signaturalgorithmus wählen, lässt sich die Benutzer-ID umschreiben.

Eine korrekte JWT-Signatur bedeutet keine korrekte Autorisierung. Wird der mid der Anfrage vertraut, erreicht eine rechtmäßige Person fremde Informationen.

Das eigene Objekt aktualisieren zu können bedeutet nicht, alle Eigenschaften ändern zu dürfen. Wird ein interner Zustand wie status automatisch gebunden, lassen sich Rechte oder Zahlstatus umschreiben.

Eine Gültigkeitsdauer des Authentifizierungscodes bedeutet keine Stärke gegen Brute-Force. Kandidatenraum und Versuchsgeschwindigkeit sind zu rechnen, die Fehlerzahl zu begrenzen.

Eine Regel in die WAF zu legen bedeutet nicht, die Schwachstelle behoben zu haben. Mit Erkennung und Sperrung wird Zeit gewonnen, die Auswirkung festgestellt, am Ende die Bibliothek aktualisiert.

flowchart TB
    accTitle: Zuordnung von Schwachstellen und Maßnahmen
    accDescr: Für Token und Authentifizierungsversuche, Ziel und Aktualisierungsfelder sowie Ausführung aus externer Eingabe jeweils Maßnahmen vorsehen.
    A["Zu vertrauende Grenzen trennen"] --> B["Token und Authentifizierungsversuche"]
    A --> C["Zieldaten und Aktualisierungsfelder"]
    A --> D["Ausführung aus externer Eingabe"]
    B --> E["Erlaubten alg festlegen, Versuche begrenzen"]
    C --> F["Subjekt abgleichen, Update-DTO beschränken"]
    D --> G["Vorläufig mildern und Bibliothek aktualisieren"]

Abbildung 24: Zuordnung von Schwachstellen und Maßnahmen. Die Maßnahmen an den gebrochenen Grenzen trennen.

Das Prinzip, das diese Aufgabe durchzieht, ist eines.

Den Erfolg der vorherigen Prüfung nicht als Grund nehmen, die nächste Vertrauensgrenze auszulassen.

In den vorangehenden Artikeln der Reihe sind gespeicherte XSS in Nachmittagsaufgabe 1 Herbst Reiwa 5 und Informationsabfluss über Gäste-WLAN in Nachmittagsaufgabe 2 Herbst Reiwa 5 erklärt. Für Prüfpunkte einer gesamten Website siehe auch IPA Sichere Website-Erstellung als Checkliste nutzen.

flowchart TB
    accTitle: Abschließende Zusammenfassung
    accDescr: Den Erfolg der vorherigen Prüfung nicht als Grund nehmen, die nächste Prüfung oder betriebliche Maßnahme auszulassen.
    A["Vorherige Prüfung gelungen"] --> B{"Erfüllt auch die nächste Prüfung?"}
    B -->|"Gesondert prüfen"| C["Urteile Grenze für Grenze aufbauen"]
    B -->|"Weil gelungen, auslassen"| D["Ungeprüfte Grenze bleibt"]
    C --> E["In alltäglichen Entwurf und Prüfung übernehmen"]

Abbildung 25: Abschließende Zusammenfassung. Vertrauensgrenzen stufenweise prüfen und keine auslassen.

Referenzlinks

Verwandte Artikel

Aktuelle Artikel mit denselben Schlagwörtern führen zu verwandten Themen weiter.

Verwandte Themen

Diese Seiten ordnen den Artikel in einen größeren Leistungs- und Entscheidungskontext ein.

Leistungen zu diesem Thema

Dieser Artikel ist direkt mit den folgenden Leistungen verbunden.

Häufige Fragen

Fragen, die in Beratungen zu diesem Artikelthema häufig gestellt werden.

Warum lässt sich jemand anderes vortäuschen, obwohl die JWT-Signaturprüfung erfolgreich war?

In dieser Aufgabe akzeptierte die JWT-Verwaltungsbibliothek das alg im JWT-Header genau so, wie der Angreifer es vorgab, und behandelte ein JWT mit alg=none als gültig – ohne Signatur. Deshalb gelingt die Prüfung auch dann, wenn die Benutzer-ID in der Payload umgeschrieben wird. Die Prüfungsantwort lautet, als zu prüfenden Wert das alg im JWT-Header heranzuziehen und zu bestätigen, dass sein Wert nicht NONE ist. In der Praxis reicht es allerdings nicht, nur NONE abzulehnen. Legen Sie in der serverseitigen Konfiguration die erlaubten Algorithmen fest, etwa auf RS256, und verwenden Sie den vom Token selbst angegebenen Algorithmus nie unmittelbar für die Auswahl. Prüfen Sie außerdem je nach Verwendungszweck issuer, audience, Gültigkeitsdauer und subject.

Reicht es als Autorisierungsmaßnahme, die Benutzer-ID im JWT mit der mid der Anfrage zu vergleichen?

Für die Zwecke dieser Prüfungsantwort ist das ausreichend. Prüft das gemeinsame Modul P, ob die im JWT enthaltene Benutzer-ID mit mid übereinstimmt, lässt sich ein Angriff stoppen, der eine fremde mid angibt. Bei einer API, die aber nur die eigenen Informationen des Aufrufenden behandelt, ist es in der Praxis sicherer, mid gar nicht erst vom Client entgegenzunehmen und die Benutzer-ID stattdessen aus dem subject des geprüften JWT zu bestimmen. Mit Endpunkten wie GET /users/me oder PUT /users/me lässt sich vermeiden, dass die Vergleichsprüfung überhaupt vergessen werden kann. Eine API, über die ein Administrator andere Nutzer bearbeitet, gehört auf einen eigenen Endpunkt mit eigener Autorisierungsrichtlinie.

Warum lässt sich der Angriff, der status hinzufügt, nicht allein durch gewöhnliche Eingabevalidierung verhindern?

Weil es nichts nützt, die Länge von name oder den Wertebereich von age zu prüfen, wenn status – ein Feld, das gar nicht erst angenommen werden sollte – ohnehin automatisch gebunden und an das interne Objekt weitergereicht wird. Das Problem ist nicht das Format eines Werts, sondern die Autorisierung auf Eigenschaftsebene: ob der Nutzer diese Eigenschaft überhaupt ändern darf. Definieren Sie im Eingabetyp für Aktualisierungen ausschließlich name und age, und lehnen Sie unbekannte Eigenschaften ab. Der Zahlungsstatus darf nur durch serverseitig vertrauenswürdige Ereignisse geändert werden, etwa das Erfolgsergebnis des Zahlungsdiensts.

Der vierstellige Authentifizierungscode verfällt nach 10 Minuten – warum ist das trotzdem gefährlich?

Weil es von 0000 bis 9999 nur 10.000 mögliche Werte gibt und bei 10 Versuchen pro Sekunde im Durchschnitt nach 5.000 Versuchen, also 500 Sekunden, der Treffer gelingt. Die Gültigkeitsdauer von 10 Minuten entspricht 600 Sekunden – probiert man sich also der Reihe nach ohne Wiederholung durch, lassen sich innerhalb der Gültigkeitsdauer 6.000 Kombinationen prüfen. Die Ablaufzeit allein stoppt ein Brute-Force nicht. Kandidatenzahl, Versuchsgeschwindigkeit und Obergrenze der Versuche müssen gemeinsam entworfen werden.

Die Prüfungsantwort ist eine Kontosperre – reicht in der Praxis auch eine sofortige Sperre allein?

Nein. In die Lücke der Aufgabe gehört zwar eine Verarbeitung, die das Konto sperrt, sobald die Anzahl aufeinanderfolgender Fehlversuche einen Schwellenwert überschreitet, doch eine feste, dauerhafte Sperre allein erlaubt einem Angreifer, absichtlich das Konto einer anderen Person zu sperren und so einen Denial-of-Service auszulösen. In der Praxis kombiniert man eine kontobezogene Fehlerzahl, gestaffelte Wartezeiten, eine Risikobewertung nach Quelle oder Gerät, Benachrichtigungen und ein Wiederherstellungsverfahren. Wichtig ist auch, dass die Fehlerzahl beim Ausstellen eines neuen Codes nicht auf null zurückgesetzt wird.

Was bringt es, die WAF auf Erkennung statt auf Sperrung zu stellen?

Dass geschäftlicher Datenverkehr auch dann nicht gestoppt wird, wenn eine normale Zeichenfolge fälschlich als Angriff eingestuft wird. Die Musterlösung nennt als Vorteil, dass sich eine Sperrung durch Fehlalarme vermeiden lässt, und als durchzuführende Maßnahme, bei Eingang eines Alarms zu prüfen, ob es sich um einen Angriff handelt. Der Erkennungsmodus ist keine Einstellung zum Sich-selbst-Überlassen. Er dient als Beobachtungszeitraum, in dem Sie Protokolle prüfen, Fehlalarme aussortieren, die Regel anpassen und dann zur Sperrung übergehen. In einem Notfall, in dem eine bekannte, kritische Schwachstelle bereits aktiv ausgenutzt wird, kann es angemessen sein, das Verfügbarkeitsrisiko gegen den Schaden abzuwägen und von Anfang an zu sperren.

Ist die Bibliothek H in dieser Aufgabe Log4j?

Der Aufgabentext verschweigt zwar den Produktnamen, doch der Ablauf des Angriffs – JNDI Lookup, ein LDAP-Server, das Nachladen einer Klasse von einem HTTP-Server, eine in einen HTTP-Header eingebettete Zeichenfolge und ein hoher CVSS-v3.1-Basiswert – lässt sich naheliegend als Abstraktion von CVE-2021-44228 lesen, bekannt als Log4Shell. Dieser Artikel erklärt diese Entsprechung, doch in der Prüfung muss der konkrete Produktname nicht genannt werden. Sie lässt sich allein aus dem vorgegebenen Angriffsablauf und der WAF-Spezifikation beantworten.

Was sollte man aus dieser Aufgabe für die eigene Praxis mitnehmen?

Dass eine erfolgreiche Authentifizierung, ein unverändertes JWT, der erlaubte Zugriff auf das Zielobjekt und die erlaubte Änderung der Zieleigenschaft allesamt getrennte Prüfungen sind. Hinzu kommt, dass ein kurzer Authentifizierungscode eine Begrenzung der Versuchszahl braucht und dass bei einer schwerwiegenden Bibliotheksschwachstelle Wirkungsprüfung, vorläufige Verteidigung und grundlegende Korrektur parallel vorangetrieben werden. Im Kern der Praxis stehen: Autorisierung in gemeinsamen Bausteinen bündeln, das Eingabeschema als Positivliste gestalten, die Prüfbedingungen des JWT serverseitig festlegen und abhängige Bibliotheken im Blick behalten, damit sie aktualisiert werden können.

Autorenprofil

Profilseite des Artikelautors.

Go Komura

Geschäftsführer von KomuraSoft LLC

Spezialisiert auf Windows-Softwareentwicklung, technische Beratung und Fehleranalyse, insbesondere bei bestehenden Systemen und schwer reproduzierbaren Störungen.