Sicherheit

JWT bezieht Schlüsselmaterial über den Token-Header (jku/x5u/kid)

Üblicher Schweregrad: hoch · Aufwand: gering

Woran du es erkennst

Der decodierbare Header eines beobachteten Tokens verweist über jku/x5u auf eine externe Schlüsselquelle — oder der kid-Header enthält Path-Traversal- beziehungsweise SQL-Zeichen.

Warum es zählt

Wer bestimmt, woher der Verifier seinen Schlüssel lädt, bestimmt die Signaturprüfung: jku/x5u ohne strikte Allowlist lädt Schlüssel von einer angreiferkontrollierten URL, und ein kid, der als Dateipfad oder SQL-Fragment interpretiert wird, lässt sich auf einen bekannten Schlüssel umlenken. Damit signiert der Angreifer gültige Tokens selbst.

So behebst du es

  1. jku- und x5u-Header nicht akzeptieren — Schlüsselmaterial kommt aus der eigenen Konfiguration; ist ein Remote-Abruf (JWKS) unvermeidbar, die URL strikt per Allowlist auf den eigenen Aussteller beschränken.
  2. kid als reine Schlüssel-ID behandeln: nur als Lookup-Schlüssel in einer Allowlist verwenden, niemals als Dateipfad oder in einer SQL-Abfrage — Zeichen wie ../ und Anführungszeichen ablehnen.
  3. Serverseitig wie bei alg eine feste Algorithmus-Allowlist erzwingen, damit der Header die Prüflogik nicht aushandeln kann.

Zum Nachlesen