JWT alg:none und Verwechslungsangriffe erklärt

Die JWT-None-Algorithmus-Schwachstelle ermöglicht es einem Angreifer, die Signatur eines Tokens zu entfernen und dessen Inhalt neu zu schreiben, wobei der Server das gefälschte Token als gültig akzeptiert. Dies tritt auf, wenn Ihr Code dem alg-Feld im Token-Header vertraut, anstatt den Algorithmus selbst zu bestimmen. Dieselbe Ursache liegt der RS256-zu-HS256-Verwechslungsattacke zugrunde. Beides sind Authentifizierungsumgehungen, die mit einer einzigen Codezeile behoben werden.

Wenn Sie JSON Web Tokens einsetzen, ist dies einer der wenigen Sicherheitsfehler, der aus einer lesenden Störung eine vollständige Account-Übernahme macht. Ein Angreifer, der ein gültiges Token fälschen kann, kann "sub": "admin" setzen, nichts signieren und sich einfach einloggen. Im Folgenden sehen Sie genau, wie jede Attacke funktioniert, mit den Bytes im Detail, plus die Allowlist-Fix, der die gesamte Fehlerklasse beendet.

Was die JWT-None-Algorithmus-Sicherheitslücke wirklich ist#

Ein JWT besteht aus drei durch Punkte getrennten Teilen: einem base64url-kodierten Header, einem base64url-kodierten Payload und einer Signatur. Der Header gibt den Algorithmus an, mit dem der Token signiert wurde, z.B. {"alg":"HS256","typ":"JWT"}. Die Signatur beweist, dass der Token nicht manipuliert wurde.

Der none-Algorithmus ist ein legitimer Bestandteil des JWT-Standards (RFC 7519). Er bedeutet, dass der Token unsigniert ist. Er existiert für Situationen, in denen die Transportschicht bereits die Integrität garantiert, sodass die Signatur absichtlich leer bleibt. Das Problem ist nicht, dass none existiert. Das Problem ist, wenn eine Verifikationsbibliothek den eigenen alg: none-Header eines Tokens als Erlaubnis behandelt, die Signaturprüfung komplett zu überspringen.

Der Kernfehler in beiden folgenden Angriffen ist identisch: Der Server liest den vom Angreifer kontrollierten alg-Header und vertraut ihm, um zu entscheiden, wie (oder ob) die Signatur überprüft wird. Lassen Sie niemals zu, dass eine nicht vertrauenswürdige Eingabe Ihren Verifikationsalgorithmus wählt.

Die Fälschung in drei Schritten#

Hier ist der Angriff gegen einen Server, der alg: none akzeptiert. Angenommen, ein echter Token entschlüsselt zu folgendem Payload:

{ "sub": "1234", "role": "user", "exp": 1735689600 }

Ein Angreifer tut drei Dinge:

1. Ändert den Header zu {"alg":"none","typ":"JWT"} und kodiert ihn base64url.
2. Bearbeitet den Payload zu {"sub":"1","role":"admin","exp":9999999999} und kodiert ihn.
3. Entfernt die Signatur, sodass der Token mit einem nachgestellten Punkt endet, ohne etwas dahinter.

Der gefälschte Token sieht so aus: eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJzdWIiOiIxIiwicm9sZSI6ImFkbWluIn0. (beachten Sie den nachgestellten Punkt). Ein anfälliger Server dekodiert den Header, sieht none, überspringt die Verifikation und gewährt Admin-Rechte. Kein Geheimnis, kein Schlüssel, kein Knacken. Sie können jeden Token in unseren kostenlosen JWT-Decoder einfügen, um genau zu sehen, welchen alg-Header er trägt, bevor Sie ihm vertrauen.

Warum "none" manchmal ein großes N hat#

Einige frühe Bibliotheken blockierten den String none groß-/kleinschreibungssensitiv, aber nicht None, NONE oder nOnE. Da der JWT-Standard Algorithmusnamen groß-/kleinschreibungssensitiv behandelt, die Praxis jedoch nicht immer, umgingen Angreifer naive Blocklisten durch Variieren der Groß-/Kleinschreibung. Dies ist die erste Lektion der JWT-Sicherheit: Eine Blockliste schlechter Werte ist fragil. Eine Positivliste guter Werte ist es nicht.

Der RS256-zu-HS256 Algorithmus-Verwechslungsangriff#

Der Verwechslungsangriff ist hinterhältiger und erwischt Teams auch 2026 noch. Er nutzt den Unterschied zwischen symmetrischer und asymmetrischer Signierung aus, wenn ein einziger Verifizierungsaufruf beide akzeptiert.

Hier sind zwei Algorithmusfamilien relevant:

• HS256 ist symmetrisch. Ein gemeinsamer Schlüssel signiert und verifiziert. Wer den Schlüssel besitzt, kann gültige Token erstellen.
• RS256 ist asymmetrisch. Ein privater Schlüssel signiert, ein öffentlicher Schlüssel verifiziert. Der öffentliche Schlüssel ist per Definition öffentlich. Es ist in Ordnung, ihn zu veröffentlichen.

Ein Server, der RS256 verwendet, bewahrt seinen privaten Schlüssel sicher auf und verifiziert eingehende Token mit dem öffentlichen Schlüssel. Das ist sicher, solange der Server nur RS256-Verifizierung durchführt.

Wie der öffentliche Schlüssel zu einem Fälschungsgeheimnis wird#

Die Verwechslung tritt auf, wenn der Verifizierungscode ungefähr so aussieht:

// ANGREIFBAR: Algorithmus aus dem Token-Header übernommen
jwt.verify(token, key);

Viele Bibliotheken lesen bei einem Token den alg-Header, um den Verifizierungspfad zu wählen. Wenn das ursprüngliche System RS256 ist, macht der Angreifer Folgendes:

1. Er besorgt sich den RSA-öffentlichen Schlüssel. Dieser ist oft an einem JWKS-Endpunkt, in einer .well-known-URL, in einem SDK oder einfach in der Dokumentation veröffentlicht.
2. Er fälscht einen Token mit dem geänderten Header {"alg":"HS256"} und einer erhöhten Nutzlast.
3. Er signiert diesen Token mit HMAC-SHA256, wobei er die exakten Bytes des öffentlichen Schlüssels als HMAC-Geheimnis verwendet.

Nun empfängt der Server einen HS256-Token. Er nimmt seinen RSA-Schlüssel (von dem er glaubte, dass er nur ein Verifizierungsschlüssel sei) und führt HMAC damit aus. Da der Angreifer mit derselben öffentlichen Schlüsselzeichenfolge signiert hat, stimmt der HMAC überein. Die Signatur wird verifiziert. Der gefälschte Admin-Token wird akzeptiert.

Der Angreifer hat Ihren harmlosen, veröffentlichten öffentlichen Schlüssel in das Geheimnis verwandelt, das Token fälscht. Er brauchte den privaten Schlüssel überhaupt nicht.

Warnung: Der kniffligste Teil bei der Reproduktion ist, die exakte Byte-Darstellung des öffentlichen Schlüssels richtig hinzubekommen (PEM mit dem abschließenden Zeilenumbruch, Header enthalten oder entfernt). Angreifer brute-forcen die wenigen gängigen Kodierungen. Behandeln Sie jede RS256-Implementierung, die auch HS256 akzeptiert, als bereits kompromittiert.

Warum dies so leicht versehentlich ausgeliefert wird#

Die Schwachstelle wird fast nie absichtlich programmiert. Sie schleicht sich ein, wenn:

• Eine Bibliothek standardmäßig den Algorithmus aus dem Token-Header ableitet.
• Ein Team von HS256 auf RS256 migriert, aber den alten Verifizierungspfad "nur für den Fall" aktiviert lässt.
• Eine Wrapper-Funktion ein generisches key-Argument akzeptiert und es an den Algorithmus weitergibt, den der Token anfordert.

Wenn Sie tiefer einsteigen möchten, warum das Dekodieren eines Tokens nicht dasselbe ist wie das Verifizieren, zeigt die Aufschlüsselung in Dekodieren vs. Verifizieren in der JWT-Sicherheit, wo Teams beides verwechseln und genau dieses Loch öffnen.

Die Lösung: Ihren Algorithmus auf die Whitelist setzen#

Beide Angriffe scheitern, sobald der Server aufhört, dem alg-Header des Tokens zu vertrauen, und stattdessen den akzeptierten Algorithmus festlegt. Dies ist die wichtigste JWT-Abwehrmaßnahme und besteht meist aus einer einzigen Zeile.

Algorithmus explizit festlegen#

In Node mit der gängigen Bibliothek jsonwebtoken übergeben Sie eine explizite algorithms-Whitelist:

// SICHER: nur HS256 wird akzeptiert
jwt.verify(token, secret, { algorithms: ["HS256"] });

// SICHER: nur RS256 mit dem ÖFFENTLICHEN Schlüssel, nichts anderes
jwt.verify(token, publicKey, { algorithms: ["RS256"] });

Mit dieser Whitelist wird ein gefälschtes Token mit alg: none abgelehnt, da none nicht in der Liste enthalten ist. Ein gefälschtes HS256-Token, das an den RS256-Verifizierer gesendet wird, wird abgelehnt, da der Verifizierer nur RS256 ausführt und HMAC-Bytes eine RSA-Signaturprüfung nicht erfüllen können.

Jede ausgereifte JWT-Bibliothek bietet dieselbe Steuerung unter einem leicht anderen Namen:

Sprache / Bibliothek	Der Whitelist-Parameter
Node jsonwebtoken	algorithms: ["RS256"] in verify()
Python PyJWT	algorithms=["RS256"] in jwt.decode()
Go golang-jwt	WithValidMethods([]string{"RS256"})
Java java-jwt (Auth0)	Verifizierer mit dem spezifischen Algorithm erstellen
PHP firebase/php-jwt	Algorithmus an JWT::decode() übergeben

Eine kurze Härtungs-Checkliste#

Das Festlegen des Algorithmus ist die wichtigste Maßnahme. Diese Gewohnheiten schließen die restlichen Lücken:

• Akzeptieren Sie none niemals in der Produktion. Es gibt keinen Grund, warum das Token eines angemeldeten Benutzers unsigniert sein sollte.
• Verwenden Sie einen Algorithmus pro Dienst. Wenn Sie nicht sowohl HS256 als auch RS256 benötigen, lassen Sie Ihren Verifizierer nicht beide akzeptieren. Die Vermischung ist es, die den Verwirrungsangriff einlädt.
• Halten Sie Verifikationsschlüssel typisiert. Laden Sie Ihren RSA-öffentlichen Schlüssel als Schlüsselobjekt, nicht als rohen String, damit er nicht versehentlich als HMAC-Geheimnis verwendet werden kann.
• Validieren Sie Claims, nicht nur die Signatur. Überprüfen Sie exp, iss und aud. Eine gültige Signatur auf einem Token, das für einen anderen Dienst bestimmt ist, ist immer noch ein Problem.
• Überprüfen Sie erhaltene Tokens. Bevor Sie ein Drittanbieter-Token integrieren, decodieren Sie es und bestätigen Sie, dass Header und Claims Ihren Erwartungen entsprechen.

Sie können dies alles in Sekunden an einem echten Token überprüfen. Unser JWT-Decoder und Sicherheitstool zeigt den Header, die Payload und den Algorithmus, den ein Token angibt, sodass Sie ein alg: none oder ein unerwartetes HS256 erkennen können, bevor es Ihren Verifizierer erreicht. Der Begleitartikel zum Lesen der JWT-Decoder-Ausgabe für Token-Sicherheit erläutert, was Ihnen jedes Feld verrät.

So erkennen Sie, ob Ihre App verwundbar ist#

Sie brauchen kein Pentest-Team, um das herauszufinden. Drei schnelle Checks decken die meisten realen Schwachstellen ab.

Schritt 1: Ist der Algorithmus festgelegt?#

Durchsuchen Sie Ihre Codebasis nach jedem Aufruf, der ein Token verifiziert. Wenn ein Verifizierungspfad eine algorithms-Zulassungsliste (oder deren Äquivalent) auslässt, vertraut dieser Pfad dem Token-Header und ist verdächtig. Dies ist der wertvollste Check und dauert nur Minuten.

Schritt 2: Kommt ein none-Token durch?#

Nehmen Sie ein gültiges Token, ändern Sie seinen Header in {"alg":"none","typ":"JWT"}, ändern Sie einen Anspruch, entfernen Sie die Signatur (behalten Sie den abschließenden Punkt) und senden Sie es an einen geschützten Endpunkt. Eine 200-Antwort mit der gefälschten Identität bestätigt die Schwachstelle. Eine 401 bestätigt, dass der Pfad sie ablehnt.

Schritt 3: Ist Ihr öffentlicher Schlüssel wirklich öffentlich und akzeptiert etwas HS256?#

Wenn Sie mit RS256 signieren, gehen Sie davon aus, dass der öffentliche Schlüssel in den Händen eines Angreifers ist. Das Einzige, was zwischen diesem und einem gefälschten Token steht, ist, ob ein Verifizierer in Ihrem Stack HS256 ausführt. Wenn die Antwort irgendwo ja lautet, sind Sie dem Verwirrungsangriff ausgesetzt, bis Sie RS256 festlegen.

Häufig gestellte Fragen#

Ist die JWT none-Algorithmus-Sicherheitslücke 2026 noch relevant? Ja. Moderne, gewartete Bibliotheken lehnen alg: none standardmäßig ab und erfordern eine explizite Whitelist, sodass eine Neuinstallation in der Regel sicher ist. Der Fehler besteht in älteren Bibliotheksversionen, in selbst geschriebenem JWT-Code und in Apps, die Standardeinstellungen überschreiben, um "Flexibilität zu unterstützen". Eine Überprüfung Ihrer Verifizierungsaufrufe ist dennoch empfehlenswert.

Warum ist die Veröffentlichung meines RS256-öffentlichen Schlüssels sicher, wenn damit Token gefälscht werden können? Der öffentliche Schlüssel allein ist harmlos. Er wird nur gefährlich, wenn Ihr Server bereit ist, die HS256-Verifizierung durchzuführen und diesen öffentlichen Schlüssel als HMAC-Geheimnis behandelt. Beheben Sie die Bereitschaft, HS256 zu akzeptieren (festlegen auf RS256), und die Veröffentlichung des öffentlichen Schlüssels ist genauso sicher, wie vom Design beabsichtigt.

Was bedeutet "Whitelist des Algorithmus" in der Praxis? Es bedeutet, dass Sie Ihrer Verify-Funktion den genauen Algorithmus oder die Algorithmen mitteilen, die Sie akzeptieren, anstatt sie den Algorithmus aus dem eingehenden Token lesen zu lassen. In jsonwebtoken ist das verify(token, key, { algorithms: ["RS256"] }). Der Verifizierer ignoriert dann den alg-Header des Tokens bei der Entscheidung, wie die Signatur geprüft wird.

Kann ich einfach den String "none" blockieren, um sicher zu sein? Nein. Blocklisten sind anfällig. Angreifer umgehen case-sensitive Blöcke mit None oder NONE, und eine Blockliste hilft nicht gegen die RS256-zu-HS256-Verwechslungsattacke, die einen völlig normalen HS256-Wert verwendet. Eine Whitelist akzeptierter Algorithmen schützt gleichzeitig vor beiden Angriffen.

Wie kann ich überprüfen, welchen Algorithmus ein Token verwendet? Dekodieren Sie das erste Segment des Tokens, das den base64url-kodierten Header mit dem alg-Feld enthält. Sie können dies manuell tun oder das Token in einen JWT-Decoder einfügen, der den Header, die Nutzlast und den deklarierten Algorithmus anzeigt. Das Dekodieren validiert nie die Signatur, behandeln Sie das Ergebnis daher als informativ, bis Ihr Server es mit einem festgelegten Algorithmus verifiziert.

Behebt ein längerer Schlüssel oder ein stärkerer Schlüssel dies? Nein. Ein 4.096-Bit-RSA-Schlüssel hilft nicht, wenn der Verifizierer in den HMAC-Modus gezwungen werden kann, und ein starkes HMAC-Geheimnis hilft nicht, wenn der Server unsignierte none-Token akzeptiert. Diese Angriffe umgehen die Kryptographie, anstatt sie zu brechen. Die Lösung ist die Festlegung des Algorithmus, nicht die Erhöhung der Schlüsselstärke.

Das Fazit zur JWT-None-Algorithmus-Sicherheitslücke#

Die Sicherheitslücke des JWT-None-Algorithmus und die RS256-zu-HS256-Verwechslungsattacke haben eine gemeinsame Ursache: Das Vertrauen auf vom Angreifer kontrollierte Eingaben, um zu entscheiden, wie ein Token verifiziert wird. Entfernen Sie eine Signatur oder tauschen Sie einen öffentlichen Schlüssel als HMAC-Geheimnis ein, und ein Server, der seine Anweisungen aus dem alg-Header liest, wird die Fälschung durchlassen.

Legen Sie den Algorithmus mit einer expliziten Positivliste fest, verweigern Sie none in der Produktion und behalten Sie einen Algorithmus pro Dienst bei. Diese wenigen Gewohnheiten eliminieren die gesamte Fehlerklasse. Wenn Sie bestätigen müssen, was ein Token tatsächlich enthält, decodieren Sie es zuerst und verifizieren Sie es dann mit einem festgelegten Algorithmus, und Sie schließen die Tür endgültig.