CVE-2026-71206 — Shiori: JWT CheckToken validiert den Kontostatus nie erneut

Produkt: go-shiori/shiori Datei: internal/domains/auth.go CWE: CWE-613 — Unzureichende Sitzungsexpiration CVSS 3.1: AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:L — 8.2 (Hoch) CNA: Turan Security · CVE-Eintrag

Beschreibung

Shioris CheckToken-Funktion (internal/domains/auth.go) validiert nur die HMAC-Signatur des JWT und gibt das eingebettete claims.Account-Objekt unverändert zurück — sie ruft das Konto bei jeder Anfrage nie erneut aus der Datenbank ab. Es existiert keinerlei Session-Speicher oder Token-Widerruf-Mechanismus in der Codebasis.

Auswirkungen

Sobald ein JWT ausgestellt wurde, bleibt es für seine gesamte Lebensdauer vollständig gültig, unabhängig davon, was danach mit dem Konto geschieht. Wenn ein Administrator einen Benutzer löscht, herabstuft oder das Passwort des Benutzers nach einem vermuteten Kompromittierungsvorfall geändert wird, authentifiziert sich jedes JWT, das diesem Konto vor der Änderung ausgestellt wurde, weiterhin erfolgreich mit den ursprünglichen Claims (Rolle, Konto-ID usw.), die im Token eingebettet sind — es gibt keinen serverseitigen Zustand, um es zu invalidieren.

Reproduktion

1. Authentifizieren Sie sich als Benutzer und erfassen Sie das ausgestellte JWT (z. B. über POST /api/v1/auth/login).
2. Löschen Sie als Administrator das Konto oder stufen Sie die Rolle des Benutzers herab.
3. Spielen Sie das ursprüngliche JWT gegen einen beliebigen authentifizierten Endpunkt erneut ab:
   root@kitploit:~

   GET /api/bookmarks
   Authorization: Bearer <original JWT>
   

4. Die Anfrage ist mit den veralteten Claims erfolgreich — das gelöschte/herabgestufte Konto hat weiterhin Zugriff, weil CheckToken nie den aktuellen Datenbankzustand prüft, sondern nur die Signatur.

Grundursache

CheckToken behandelt die JWT-Nutzlast als maßgebliche Quelle für den Kontostatus, anstatt sie als Bearer-Credential zu behandeln, das bei jeder Verwendung erneut gegen die Datenbank validiert (oder gegen eine Widerrufsliste geprüft) werden muss.

Empfohlene Behebung

Rufen Sie das Konto bei jeder authentifizierten Anfrage erneut anhand der ID ab (oder prüfen Sie das Token zumindest gegen einen Widerrufs-/Session-Speicher, der nach einer Token-ID (jti) schlüsselt und bei Kontolöschung, Herabstufung oder Passwortänderung invalidiert wird), anstatt den eingebetteten Claims unverändert zu vertrauen.