Entwicklertools · JWT Decoder
Zielgruppen- und Emittentenprüfungen: Verhindern, dass ein JWT an anderer Stelle wiedergegeben wird
· Warum es wichtig ist
jwt Authentifizierung Sicherheit
Ein für einen Dienst ausgestellter Token kann einem anderen Dienst vorgelegt werden, der denselben Aussteller hat. In diesem Beitrag wird erläutert, wie aud- und iss-Prüfungen dies verhindern und wie beide Ansprüche in einem Token gelesen werden.
Dienst B akzeptiert ein Token, das für Dienst A bestimmt ist – die dienstübergreifende Wiedergabe, die eine gültige Signatur nicht verhindert
Eine Signatur kann für einen Token gültig sein, der für einen anderen Dienst ausgestellt wurde. Wenn mehrere APIs derselben Identitätsplattform vertrauen, aber den Empfängerkontext ignorieren, können Anmeldeinformationen, die für Dienst A bestimmt sind, bei Dienst B wiedergegeben werden. Die kryptografische Integrität allein gibt keine Antwort darauf, wer sie nutzen soll.
ToolAcre kann `iss` und `aud` offenlegen, sodass ein Entwickler eine offensichtliche Nichtübereinstimmung erkennen kann. Diese Zeichenfolgen bleiben ungeprüft, bis die Signatur erfolgreich ist, und das Browser-Tool führt diese Prüfung nie durch. Der eigentliche Ressourcenserver muss sowohl seine Emittentenbeziehung als auch seine beabsichtigte Zielgruppe durchsetzen.
iss – Bindung eines Tokens an den Aussteller, dem Ihr Dienst vertraut, und warum eine Zeichenfolgenübereinstimmung ohne Schlüsselbindung nicht ausreicht
`iss` identifiziert die Entität, von der die Nutzlast behauptet, dass sie das Token ausgegeben hat. Ein Verifizierer benötigt einen genauen erwarteten Aussteller in seiner eigenen Konfiguration und muss diese Identität an die richtige Schlüssel-Erkennungsbeziehung binden. Der Vergleich von Text ohne die kryptografische Bindung lässt einem Angreifer Raum, die erwartete Zeichenfolge zu kopieren.
Der Decoder beschreibt `iss` als „wer das Token erstellt hat“, aber das ist die registrierte Bedeutung und keine Feststellung über einen eingefügten Wert. Lesbarer Ausstellertext ist ein nützlicher Beweis für das Debugging der Konfiguration. Es kann keine beliebige Schlüsselquelle auswählen oder sich selbst authentifizieren.
aud – eine Zeichenfolge oder ein Array, das die beabsichtigten Empfänger benennt, und die Regel, dass sich ein Verifizierer darin befinden muss
`aud` benennt die vorgesehenen Empfänger und kann als einzelne Zeichenfolge oder Sammlung erscheinen. Die Richtlinie des Ressourcenservers muss sich im authentifizierten Wert wiederfinden und dabei die genauen Vergleichsregeln verwenden, die für sein Profil erforderlich sind. Es sollte kein Token akzeptiert werden, nur weil ein anderer bekannter Dienst aufgeführt ist.
ToolAcre trägt Arrays als JSON-Text in seiner Anspruchstabelle und behält so ihre sichtbare Struktur zur Überprüfung bei. Es kennt die Kennung der aktuellen API nicht und kann keine Übereinstimmung feststellen. Dieses absichtliche Fehlen hindert einen generischen Decoder daran, einen Autorisierungskontext zu erfinden, über den er nicht verfügt.
azp und Scope – die OpenID Connect- und OAuth-Ansprüche, die festlegen, wer das Token wofür verwenden darf
`azp` und `scope` können Kontext zu einer autorisierten Partei und angeforderten Berechtigungen in Profilen hinzufügen, die sie definieren. Sie ersetzen keine Zielgruppen-, Emittenten- oder Unterschriftenprüfung. Ein Bereichsname ist eine Behauptung und keine Berechtigungserteilung, bis der Ressourcenserver einen authentifizierten Wert seiner eigenen Richtlinie zuordnet.
Der aktuelle Decoder behandelt diese als anwendungsspezifische Ansprüche, da seine Tabelle mit registrierten Beschreibungen sieben Kernnamen abdeckt. Es zeigt deren Werte an, liefert jedoch keine OpenID Connect- oder OAuth-Semantik. Konsultieren Sie das entsprechende Profil und den Anbietervertrag, bevor Sie diese in einer Entscheidung verwenden.
Das „Confused-Deputy“-Muster – wie ein legitimer Token zu einem Angriff wird, wenn die Zielgruppen nicht überprüft werden
Ein verwirrter Stellvertreter nutzt legitime Autorität in einem unbeabsichtigten Kontext. Ein vom falschen Dienst akzeptierter Token kann genau dieses Muster auslösen, selbst wenn niemand die Signatur gefälscht hat. Zielgruppenprüfungen begrenzen, wo authentifizierte Ansprüche angewendet werden können, während Ausstellerprüfungen einschränken, wessen Behauptungen der Dienst berücksichtigt.
Aus diesem Grund wäre ein allgemeines Flag „Signatur gültig“ immer noch unzureichend. Die Autorisierung ist abhängig vom Empfänger und Betrieb. ToolAcre vermeidet diese Mehrdeutigkeit vollständig, indem es kein Überprüfungsergebnis meldet und es dem verbrauchenden Dienst überlässt, Kryptografie mit kontextbezogenen Richtlinien zu kombinieren.
Funktioniertes Beispiel – Lesen von iss und aud von zwei Token im ToolAcre JWT-Decoder und Entscheiden, welcher Dienst jeweils akzeptiert werden soll
Erstellen Sie zwei harmlose Token, deren entschlüsselte Nutzlasten sich nur in `aud` unterscheiden: einer heißt `service-a`, der andere `service-b`; beide beanspruchen denselben Emittenten. ToolAcre macht den Unterschied sichtbar. Ein Dienst-A-Verifizierer sollte keines von beiden nur aufgrund dieser Anzeige akzeptieren und die authentifizierte Dienst-B-Zielgruppe ablehnen.
Dann kehren Sie die Übung mit zwei Emittentenzeichenfolgen um. Der erwartete Text allein reicht nicht aus, es sei denn, bei der Überprüfung wurden für diesen Aussteller vertrauenswürdige Schlüssel verwendet. Diese Beispiele trennen die Inspektion von der Annahme und zeigen, warum das Kopieren der richtigen Ansprüche in einen gefälschten Token keine vertrauenswürdige Richtlinie ändert.
Was dies nicht abdeckt: Signaturüberprüfung, die der Decoder niemals durchführt; aud- und iss-Prüfungen sind erst dann von Bedeutung, wenn die Signatur gültig ist
Zielgruppen- und Emittentenprüfungen sind erst dann von Bedeutung, wenn die kryptografische Überprüfung ergibt, dass die geschützten Bytes vertrauenswürdigem Schlüsselmaterial entsprechen. ToolAcre führt keine dieser Überprüfungen durch. Seine Ausgabe kann nicht belegen, dass ein Anspruch unversehrt geblieben ist oder dass ein bekannter Aussteller ihn verfasst hat.
Außerdem werden keine Metadaten abgerufen, keine Schlüssel ausgewählt oder konfigurierte Empfänger verglichen. Verwenden Sie Backend-Tests und Protokolle, um die Ablehnung für den falschen Aussteller und die falsche Zielgruppe nachzuweisen. Eine visuelle Übereinstimmung in einem Decoder ist ein Debugging-Hinweis und niemals ein ausreichender Autorisierungsbeweis.
Takeaway: Überprüfen Sie, für wen es bestimmt ist, nicht nur, wer es unterzeichnet hat – der ToolAcre JWT-Decoder zeigt die aud- und iss-Ansprüche an, die Sie vergleichen müssen
Überprüfen Sie, für wen das Token bestimmt ist, und nicht nur für den Namen, der es unterzeichnet hat. Der robuste Ablauf authentifiziert geschützte Bytes unter einer unabhängig vertrauenswürdigen Emittentenbeziehung, erfordert dann eine akzeptable Zielgruppe und wendet dienstspezifische Autorisierungsregeln an.
Verwenden Sie ToolAcre, um sichere Testwerte zu lesen und die nächste serverseitige Prüfung zu formulieren. Wählen Sie keine Verifizierungsschlüssel aus nicht vertrauenswürdigen Header- oder Anspruchsdaten aus und wandeln Sie die angezeigten `iss`, `aud`, `azp` oder `scope` nicht in eine Gewährung ohne den vollständig vertrauenswürdigen Ablauf um.