Entwicklertools · JWT Decoder
Der alg:none-Angriff und die Schlüsselverwirrung: Warum Verifizierer Algorithmen pinnen müssen
· Warum es wichtig ist
jwt Sicherheit Kryptographie
Wenn ein Verifizierer dem Token erlaubt, seinen eigenen Algorithmus auszuwählen, kann ein Angreifer keinen auswählen oder RSA gegen HMAC austauschen. In diesem Beitrag werden beide Angriffe und die Regel, die sie verhindert, erläutert.
Das Token, das sich selbst verifizierte – wie ein Header-Feld zur Angriffsfläche wurde
Ein Algorithmus-Label befindet sich in der vom Angreifer kontrollierten Token-Eingabe. Wenn ein Verifizierer diese Bezeichnung als Erlaubnis zur Auswahl eines verfügbaren Validierungsmodus behandelt, beginnt das Token, die Regel zu beeinflussen, die zu seiner Beurteilung verwendet wird. ToolAcre stellt das Etikett präzise zur Verfügung, damit Prüfer es sehen können, reagiert jedoch nie kryptografisch darauf.
Die sichere Richtung ist umgekehrt: Die Konfiguration des vertrauenswürdigen Dienstes definiert akzeptable Algorithmenfamilien und zugehörige Schlüssel, dann müssen eingehende Header dieser Richtlinie entsprechen. Ein Dekodierungspanel kann diese Richtlinie nicht liefern und darf nicht mit Schutz verwechselt werden, nur weil es einen verdächtigen Wert hervorhebt.
Das Repository markiert alg:none, erstellt jedoch nicht den Spezifikationsverlauf hinter ungesicherten JWTs
Die Implementierung behandelt `alg: none` als eine nicht signierte Deklaration und warnt, dass ihre Annahme willkürlichen Inhalt akzeptieren würde. Außerdem wird ein leeres drittes Segment separat gemeldet. Die Repository-Beweise unterstützen die Ablehnung solcher Eingaben in authentifizierten Arbeitsabläufen; Es wird nicht dokumentiert, warum ungesicherte JWTs ursprünglich in einer Spezifikation enthalten waren.
Dieser historische Wortlaut ist daher eher korrigiert als erfunden. Was operativ wichtig ist, ist klar: Ein Dienst, der signierte Anmeldeinformationen erwartet, darf nicht zulassen, dass ein Token-Header die Signaturprüfung deaktiviert. ToolAcre selbst führt keine Überprüfung durch, sodass seine Fähigkeit, `none` anzuzeigen, nur zur Erkennung und Inspektion dient.
Der alg:none-Angriff – Entfernen der Signatur und Aufforderung an den Verifizierer, eine leere Signatur zu akzeptieren
Ein unsignierter Angriff ändert den Header zur Anforderung `none`, ändert bei Bedarf Ansprüche und liefert keine Signaturbytes. Jedes Segment kann weiterhin syntaktisch gültig sein und die ersten beiden werden in poliertes JSON dekodiert. Ein freizügiger Verifizierer würde die Präferenz des Angreifers in eine Umgehung der Authentifizierung umwandeln.
Ein strenger Verifizierer verfügt über keinen Zweig, der diese Eingabe auf den vertrauenswürdigen Status hochstuft, wenn signierte Token erforderlich sind. Die Warnung von ToolAcre hilft dabei, die Form beim Debuggen zu identifizieren, aber das Lesen des Wortes `none` hindert ein Backend nicht daran, eine schlechte Entscheidung zu treffen. Die Durchsetzung gehört dorthin, wo der Berechtigungsnachweis verbraucht wird.
Schlüsselverwirrung – Darstellung eines öffentlichen Schlüssels als HMAC-Geheimnis, sodass RS256-Token als HS256 verifiziert werden
Schlüsselverwirrung entsteht, wenn ein Verifizierer Algorithmusfamilien mit inkompatiblen Schlüsselrollen zulässt und nicht jede Auswahl an den richtigen Schlüsseltyp bindet. Ein öffentlicher RSA-Verifizierungsschlüssel ist kein HMAC-Geheimnis. Wenn seine Bytes als eins behandelt werden, nachdem ein Angreifer eine Algorithmusbezeichnung geändert hat, wird die beabsichtigte public/private-Trennung zunichte gemacht.
Um diese Fehlerklasse zu verhindern, ist mehr als die Prüfung auf ein signaturförmiges Segment erforderlich. Der Dienst muss den erwarteten Algorithmus, den Schlüsseltyp, den Aussteller und das Tokenprofil über eine vertrauenswürdige Konfiguration koppeln. Ein Decoder, der RS256 oder HS256 anzeigt, kann nicht erkennen, ob das Backend diese Bindungen beibehält.
Die Lösung – pinnen Sie die akzeptierten Algorithmen im Verifizierer und leiten Sie sie niemals vom Token ab
Befestigen Sie akzeptierte Algorithmen in der Verifiziererkonfiguration und halten Sie die Liste so eng, wie es der Emittentenvertrag zulässt. Lehnen Sie `none` für signierte Anmeldeinformationsflüsse ab und lehnen Sie Nichtübereinstimmungen ab, anstatt einen anderen Algorithmus auszuprobieren. Leiten Sie die Zulassungsliste nicht aus dem nicht überprüften Header oder einem Nutzlastanspruch ab.
Die Schlüsselsuche folgt dem gleichen Prinzip. Ein `kid` kann unter bereits vertrauenswürdigen Kandidaten auswählen, darf jedoch keine neue Vertrauensquelle erstellen. Header-URLs oder eingebettete Schlüssel sollten nicht befolgt werden, nur weil das Token sie anfordert. Der Prüfer entscheidet selbstständig über seine Quellen.
Funktioniertes Beispiel – Lesen eines Headers im ToolAcre JWT-Decoder, um alg:none zu erkennen, und warum das Erkennen nicht dasselbe ist wie geschützt zu sein
Erstellen Sie einen harmlosen Token-Header mit der Deklaration `none` und lassen Sie das dritte Segment leer. ToolAcre dekodiert JSON, meldet den deklarierten Algorithmus, warnt, dass er nicht signiert ist, und notiert die fehlende Signatur. Dies ist genau das Verhalten, das von einem Inspektionstool erwartet wird.
Die Übung beweist nicht, dass eine API das Token ablehnt. Bestätigen Sie dies separat mit einem kontrollierten Negativtest anhand des tatsächlichen Verifizierers und der Konfiguration. Wenn die API dies akzeptiert, gehört der Fix in diese Überprüfungsgrenze; Das Hinzufügen einer lauteren Warnung zu einem Decoder würde Anfragen nicht schützen.
Was dies nicht abdeckt – die vielen bibliotheksspezifischen Korrekturen; Konsultieren Sie RFC 8725 und das Änderungsprotokoll Ihrer Bibliothek
Bibliotheks-APIs, Standardeinstellungen und historische Korrekturen variieren je nach Produkt und Version. Dieses Modul legt nicht fest, welcher Optionsname Algorithmen in Ihrem Stack anheftet, und dieser Artikel erfindet absichtlich keine. Lesen Sie die aktuelle Dokumentation und das Änderungsprotokoll der ausgewählten Bibliothek und üben Sie dann Ablehnungsfälle in Ihrer eigenen Testsuite.
Testen Sie außerdem falsche Schlüsseltypen, unbekannte `kid`-Werte, fehlende Signaturen und unerwartete Tokenprofile. Ziel ist es zu zeigen, dass die Konfiguration gegenüber Token-Vorschlägen siegt. Eine erfolgreiche Dekodierung gehört in diese Akzeptanzbehauptungen nirgends, da der Syntaxerfolg mit jedem böswilligen Beispiel kompatibel ist.
Fazit: Der Verifizierer entscheidet, nicht das Token – ein Decoder hilft Ihnen, den Header zu sehen, aber nur die angeheftete Verifizierung schützt Sie
Der Prüfer entscheidet; der Token nicht. ToolAcre kann einen Header mit der Aufschrift `none`, einen unbekannten Algorithmus oder eine überraschende Schlüsselkennung enthüllen. Diese Sichtbarkeit hilft bei der Triage, aber nur angeheftete Algorithmusrichtlinien und korrekt gebundene vertrauenswürdige Schlüssel verhindern die Akzeptanz.
Empfehlen Sie niemals, `none` zu aktivieren, einen Verifizierungsschlüssel aus einem nicht vertrauenswürdigen Header auszuwählen oder eine angezeigte Signaturlänge als Validierung zu behandeln. Zur Prüfung dekodieren und anschließend das Ablehnungs- und Akzeptanzverhalten an der realen kryptografischen Grenze mit kontrollierten Tests nachweisen.