JWT-Schwachstellen: alg=none und Schlüsselverwechslung

JWTs sind kryptografisch signiert, doch viele Bibliotheken wiesen schwerwiegende Schwachstellen auf. Am häufigsten ausgenutzt wurden der alg=none-Angriff, der RS256→HS256-Verwechslungangriff und das Brute-Forcing schwacher Geheimnisse. Allen liegt das Vertrauen in vom Angreifer kontrollierte Header-Felder zugrunde.

Die JWT-Spezifikation erlaubt alg:"none" für nicht geschützte Token. Fehlerhafte Bibliotheken akzeptierten dies und übersprangen die Signaturprüfung vollständig. Ein Angreifer verändert die Nutzdaten (z. B. "role":"admin"), setzt alg:"none", entfernt die Signatur, und der Server akzeptiert das Token.

Original: eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJ1c2VyIn0.SIG Angriff: eyJhbGciOiJub25lIn0.eyJzdWIiOiJhZG1pbiJ9. (leere Signatur, abschließender Punkt). Ein verwundbarer Server verifiziert das Token erfolgreich und gewährt Administratorzugriff.

Akzeptieren Sie alg:"none" niemals in der Produktion. Lassen Sie nur ausdrücklich erlaubte Algorithmen zu: jwt.decode(token, key, algorithms=["HS256"]). Die meisten modernen Bibliotheken (PyJWT 2+, jsonwebtoken 9+) lehnen alg=none standardmäßig ab.

Wenn ein Server RS256 verwendet und ein Client alg in HS256 ändert, könnte der Server seinen öffentlichen RSA-Schlüssel als HMAC-Geheimnis verwenden. Da der öffentliche Schlüssel ... öffentlich ist, signiert der Angreifer damit beliebige Nutzdaten, und der Server verifiziert sie.

Schritte: 1) Rufen Sie den öffentlichen Schlüssel vom JWKS-Endpunkt ab. 2) Erstellen Sie schädliche Nutzdaten. 3) Signieren Sie sie mit HMAC-SHA256 und den unveränderten PEM-Bytes des öffentlichen Schlüssels als HMAC-Geheimnis. 4) Setzen Sie alg:"HS256" im Header. 5) Der HS256-Pfad des Servers verifiziert das Token erfolgreich.

Geben Sie den erwarteten Algorithmus im Verifizierungsaufruf immer ausdrücklich an. Leiten Sie den Algorithmus niemals aus dem Token-Header ab. Verwenden Sie getrennte Codepfade für RS256 und HS256, die vom Aufrufer nicht umgeschaltet werden können.

HS256 mit schwachen Geheimnissen (weniger als 256 Bit Entropie) kann offline per Brute-Force angegriffen werden. Tools wie hashcat unterstützen das Knacken von JWTs: hashcat -a 0 -m 16500 token.txt wordlist.txt. Verwenden Sie kryptografisch zufällige Geheimnisse mit mindestens 32 Byte.

Der kid-Header bestimmt, welcher Schlüssel verwendet wird. Wenn der Server kid ohne Bereinigung als SQL-Abfrageparameter oder Dateisystempfad verwendet: kid="../../dev/null" → HMAC mit leerem Schlüssel → gefälschtes Token wird akzeptiert. Bereinigen Sie kid immer.

Der jwk-Header bettet einen öffentlichen Schlüssel zur Verifizierung ein. Ein verwundbarer Server könnte den eingebetteten Schlüssel direkt verwenden, sodass der Angreifer sein eigenes Schlüsselpaar bereitstellt, das Token mit dem privaten Schlüssel signiert und den öffentlichen Schlüssel einbettet. Verifizieren Sie ausschließlich gegen registrierte Schlüssel.

Manche Implementierungen vergaßen, den exp-Claim zu prüfen, oder verwendeten die Serverzeit uneinheitlich. Validieren Sie exp, nbf und iat immer ausdrücklich. Verwenden Sie eine Bibliothek, die diese Claims standardmäßig prüft, und deaktivieren Sie die Claim-Validierung niemals in der Produktion.

JWT-Schwachstellen entstehen durch das Vertrauen in den alg-Header, die Akzeptanz von alg=none und schwache Geheimnisse. Lösung: Legen Sie die Algorithmen beim Verifizierer fest, verwenden Sie starke Geheimnisse und bereinigen Sie kid. Als Nächstes: sichere Verfahren zur Implementierung von JWTs.