HS256- und RS256-Confusion-Angriffe
Wie Algorithmusverwechslung entsteht, wenn Verifier symmetrische und asymmetrische Annahmen mischen.
Algorithmusverwechslung bei JWT klingt sehr speziell, bis man einen Dienst mit drei Authentifizierungsbibliotheken und einem gemeinsamen Helper namens verifyToken findet. Der klassische Angriff nutzt einen Verifier aus, der HS256 und RS256 akzeptiert und dabei dasselbe Schlüsselmaterial in der falschen Rolle verwendet. Behandelt der Server einen öffentlichen RSA-Schlüssel als HMAC-Secret, kann ein Angreifer ein gefälschtes HS256-Token mit Daten signieren, die nie geheim sein sollten.
Warum der Fehler Reviews überlebt
Im Code Review sieht man jwt.verify(token, key) und geht weiter. Die gefährliche Entscheidung steckt in Defaults: welche Algorithmen akzeptiert werden, wie der Schlüssel gewählt wird und ob der Code anhand des Token-Headers verzweigt. Teams kopieren außerdem Snippets zwischen Services. Ein Public-Key-String, der in einem RS256-Verifier sicher war, wird riskant, wenn er an einen Verifier übergeben wird, der dem eingehenden alg vertraut.
Angreifer suchen nach offenen JWKS-Endpunkten, PEM-Dateien in mobilen Apps, Frontend-Bundles, Dokumentationsbeispielen und Fehlermeldungen, die das Verifier-Verhalten verraten. Sobald ein öffentlicher Schlüssel verfügbar ist, erzeugen sie ein Token mit alg gleich HS256, signieren den Payload mit den Bytes dieses Public Keys als HMAC-Secret und prüfen die Annahme. Die Payload-Änderung ist oft klein: scope erhöhen, tenant_id wechseln oder admin auf true setzen.
Testen ohne unnötigen Lärm
Nutze ein Konto mit niedrigen Rechten und ziele zuerst auf einen nicht destruktiven Endpunkt, etwa Profilmetadaten oder eine Feature-Flag-Route. Halte iss, aud und exp gültig, damit eine Ablehnung klarer auf die Signaturbehandlung verweist. invalid algorithm ist ein gutes Zeichen. Bei invalid signature musst du klären, ob der Algorithmus gepinnt ist oder dein Key-Format nicht passt. PEM-Header, Zeilenumbrüche und Leerzeichen am Ende können das Ergebnis verändern.
Defensive Checkliste
Pinne Algorithmen pro Issuer. Der Token-Header darf nicht entscheiden, ob ein Schlüssel symmetrisch oder asymmetrisch ist. HMAC-Secrets und RSA- oder EC-Public-Keys gehören in getrennte Konfigurationspfade, idealerweise mit getrennten Typen. Ein RS256-Verifier sollte mit einem HMAC-Secret nicht starten, und ein HS256-Verifier sollte nie einen Public Key aus JWKS laden.
Die operative Lehre
Die Lösung ist klare Trennung. Ein Issuer, eine erwartete Algorithmusfamilie, eine Schlüsselquelle, ein Verifikations-Wrapper. Wenn eine Migration von HS256 auf RS256 läuft, akzeptiere nicht beide Algorithmen unbegrenzt für dieselbe Audience. Lege ein kurzes Überschneidungsfenster fest, beobachte die Nutzung des alten Algorithmus und entferne den Fallback danach.