Ein Pentest meldet, dass deine API JWTs mit `alg: none` akzeptiert. Was ist die Auswirkung und die Behebung?
Kurzantwort
`alg: none` erlaubt jedem, ein gültig aussehendes, unsigniertes Token zu fälschen und sich als beliebiger Benutzer auszugeben — eine vollständige Authentifizierungsumgehung, kein Nebenfund. Behebe es, indem du serverseitig eine Allow-Liste der erwarteten Algorithmen führst und die Signatur stets mit dem richtigen Schlüssel prüfst; vertraue niemals dem alg-Header des Tokens für die Wahl der Prüfmethode. Längere Gültigkeit oder ein anderer Speicherort ändert nichts an gefälschten, unsignierten Tokens. Es ist kritisch und ausnutzbar, also ist Dokumentieren keine Behebung.
Die Sicherheit eines JWT beruht vollständig auf seiner Signatur. Das alg-Feld im Header sagt dem Prüfer, welcher Algorithmus verwendet wurde — aber wenn der Server diesem Feld vertraut und none erlaubt ist, überspringt er die Signaturprüfung vollständig. Ein Angreifer sendet dann ein Token mit dem Header {"alg":"none"}, einer beliebigen Nutzlast (etwa einem anderen sub oder einer Admin-Rolle) und einer leeren Signatur. Der Server hält es für gültig.
Warum das kritisch und nicht kosmetisch ist
Das ist eine vollständige Authentifizierungsumgehung. Der Angreifer muss keinen Schlüssel knacken und kein Geheimnis erraten — er behauptet einfach, wer er ist, und der Server glaubt ihm. Er kann sich als beliebiger Benutzer ausgeben, auch als Administrator, mit einem in Sekunden gefälschten Token. Das ist das schwerwiegendste Ergebnis, das ein Auth-System haben kann, weshalb die Option „geringe Auswirkung, dokumentieren" gefährlich falsch ist.
Die korrekte Behebung
- Serverseitig eine Allow-Liste der erwarteten Algorithmen führen (z. B. nur
RS256). Lehne alles andere ab und lehnenoneexplizit ab. - Immer die Signatur prüfen mit dem richtigen Schlüssel, bevor irgendein Claim gelesen wird.
- Niemals den
alg-Header des Tokens den Prüfpfad wählen lassen. Das Entkoppeln des Vertrauens von angreiferkontrollierten Eingaben blockiert auch den Algorithmus-Verwechslungsangriff, bei dem ein Token vonRS256aufHS256umgestellt wird, sodass der öffentliche Schlüssel als HMAC-Geheimnis missbraucht wird.
Warum die Distraktoren scheitern
- Längere Gültigkeit ändert, wie lange ein legitimes Token lebt; sie ändert nichts an Tokens, die nie gültig signiert wurden.
- Das Token in ein Cookie verschieben betrifft Transport und XSS/CSRF-Exposition, nicht aber, ob ein gefälschtes unsigniertes Token akzeptiert wird.
Worauf der Interviewer achtet
Ob du verstehst, dass die Signatur der gesamte Vertrauensanker ist, die Umgehung klar erklären kannst und zu einer serverseitigen Algorithmus-Allow-Liste mit verpflichtender Prüfung greifst — das Urteilsvermögen, das von einem Senior-AppSec-Engineer erwartet wird.
Wahrscheinliche Anschlussfragen
- Wie funktioniert der verwandte `RS256`-zu-`HS256`-Verwechslungsangriff und wie verhinderst du ihn?
- Wo sollte die Algorithmus-Allow-Liste liegen und warum muss sie serverseitig sein?
- Wie würdest du versuchte `alg: none`-Fälschungen in deinen Logs erkennen?