Wie funktionieren JWTs und auf welche Sicherheitsfallstricke sollte man achten?
Kurzantwort
Ein JWT besteht aus drei base64url-Teilen – Header, Payload (Claims) und Signatur – durch Punkte verbunden. Der Server signiert Header und Payload mit einem Geheimnis oder privaten Schlüssel und verifiziert diese Signatur bei jeder Anfrage, um den Claims ohne serverseitigen Sitzungszustand zu vertrauen. Fallstricke: alg=none akzeptieren, RS256-zu-HS256-Schlüsselverwechslung, Ablauf/Aussteller/Zielgruppe nicht zu validieren, Geheimnisse in die lesbare Payload zu legen und keinen Widerrufsweg zu haben.
JWTs kommen in AppSec-Interviews ständig vor, weil sie einfach zu nutzen und einfach falsch zu nutzen sind. Der Interviewer will bestätigen, dass du weißt, dass sie signiert, nicht verschlüsselt sind, und dass du die klassischen Implementierungsfallen benennen kannst.
Wie ein JWT aufgebaut ist
Ein JWT hat drei durch Punkte getrennte base64url-codierte Teile: einen Header (Algorithmus und Token-Typ), eine Payload aus Claims (Subjekt, Ablauf, Aussteller, Zielgruppe, Rollen) und eine Signatur. Der Server erstellt die Signatur über Header und Payload entweder mit einem gemeinsamen Geheimnis (HS256) oder einem privaten Schlüssel (RS256). Bei jeder Anfrage berechnet/verifiziert er diese Signatur neu; ist sie gültig, kann den Claims ohne serverseitige Sitzungssuche vertraut werden. Diese Zustandslosigkeit ist der Reiz – und die Quelle der meisten Probleme.
Die Fallstricke
alg=none. Manche Bibliotheken honorierten historisch einen Header, der „keine Signatur" angab, sodass ein Angreifer die Signatur entfernen und beliebige Claims fälschen konnte. Fixiere stets den erwarteten Algorithmus serverseitig, statt dem Header zu vertrauen.- Schlüsselverwechslung (RS256 → HS256). Nutzt der Server den öffentlichen RSA-Schlüssel als HMAC-Geheimnis, kann ein Angreifer ein gefälschtes Token mit diesem öffentlichen Schlüssel signieren. Lehne Algorithmuswechsel ab.
- Fehlende Claim-Validierung. Eine Signatur beweist nur, dass das Token nicht manipuliert wurde – du musst dennoch Ablauf (
exp), Aussteller (iss) und Zielgruppe (aud) prüfen. Tokens ohne Ablauf leben ewig. - Es als vertraulich behandeln. Die Payload ist nur base64, vollständig lesbar. Lege niemals Geheimnisse hinein.
- Kein Widerruf. Da JWTs zustandslos sind, ist ein gestohlenes Token bis zum Ablauf gültig. Nutze kurze Lebensdauern plus Refresh-Tokens oder eine Sperrliste für Notfälle.
Worauf Interviewer achten
Die Header/Payload/Signatur-Struktur, „signiert, nicht verschlüsselt", explizite Algorithmusfixierung, um alg=none und Schlüsselverwechslung zu beseitigen, das Validieren von exp/iss/aud und das Bewusstsein, dass der Widerruf der schwierige Teil zustandsloser Tokens ist.
Wahrscheinliche Anschlussfragen
- Warum ist die alg=none-Schwachstelle so gefährlich und wie verhindert man sie?
- Wie lässt die RS256-zu-HS256-Schlüsselverwechslung einen Angreifer Tokens fälschen?
- Wie widerruft man ein zustandsloses JWT, bevor es abläuft?