11. Security Considerations (Sicherheitsüberlegungen)

In DPoP wird die Verhinderung der Token-Wiederverwendung an einem anderen Endpunkt (siehe Abschnitt 2) durch die Authentifizierung des Servers gemäß [RFC6125] und die Bindung des DPoP-Proofs an einen bestimmten URI und eine bestimmte HTTP-Methode erreicht. DPoP hat jedoch eine etwas andere Art des Schutzes als TLS-basierte Methoden wie OAuth Mutual TLS [RFC8705] oder OAuth Token Binding [TOKEN-BINDING] (siehe auch Abschnitte 11.1 und 11.7). TLS-basierte Mechanismen können eine enge Integration zwischen der TLS-Schicht und der Anwendungsschicht nutzen, um eine starke Nachrichtenintegrität, Authentizität und Replay-Schutz zu erreichen.

11.1. Wiederverwendung (Replay) von DPoP-Proofs

Wenn es einem Angreifer gelingt, an ein DPoP-Proof-JWT zu gelangen, kann er das Token am selben Endpunkt erneut abspielen (Replay) (der Endpunkt und die HTTP-Methode werden über die entsprechenden Claims im JWT erzwungen). Um dies zu begrenzen, MÜSSEN Server DPoP-Proofs nur für eine begrenzte Zeit nach ihrer Erstellung akzeptieren (vorzugsweise für einen relativ kurzen Zeitraum in der Größenordnung von Sekunden oder Minuten).

Im Kontext des Ziel-URI können Server den jti-Wert jedes DPoP-Proofs für das Zeitfenster speichern, in dem das entsprechende DPoP-Proof-JWT akzeptiert würde, um zu verhindern, dass derselbe DPoP-Proof mehr als einmal verwendet wird. HTTP-Anforderungen an denselben URI, für die der jti-Wert bereits gesehen wurde, würden abgelehnt. Bei strikter Durchsetzung bietet eine solche Einmalprüfungsfunktion einen sehr starken Schutz gegen die Wiederverwendung von DPoP-Proofs, ist jedoch in der Praxis nicht immer realisierbar, z. B. wenn mehrere Server hinter einem Endpunkt keinen gemeinsamen Zustand teilen.

Zum Schutz vor Speichererschöpfungsangriffen SOLLTEN Server, die jti-Werte verfolgen, DPoP-Proof-JWTs mit unnötig großen jti-Werten ablehnen oder nur deren Hash speichern.

Hinweis: Um Uhrendrift zu berücksichtigen, KÖNNEN Server DPoP-Proofs akzeptieren, deren iat-Zeit vernünftigerweise in der nahen Zukunft liegt (in der Größenordnung von Sekunden oder Minuten). Da die Uhrendrift zwischen Server und Client signifikant sein kann, KÖNNEN Server die Lebensdauer von DPoP-Proofs durch Verwendung von vom Server bereitgestellten Nonce-Werten begrenzen, die die Serverzeit enthalten, anstatt die vom Client bereitgestellte iat-Zeit mit der Serverzeit zu vergleichen. Eine auf diese Weise erstellte Nonce liefert auch bei beliebig großer Uhrendrift das gleiche Ergebnis.

Vom Server bereitgestellte Nonces sind ein wirksames Mittel, um die Erfolgschancen einer DPoP-Proof-Wiederverwendung weiter zu verringern. Im Gegensatz zu kryptografischen Nonces ist es akzeptabel, wenn der Client dieselbe Nonce mehrmals verwendet und der Server dieselbe Nonce mehrmals akzeptiert. Solange jti-Werte verfolgt und Duplikate während der Gültigkeit der Nonce abgelehnt werden, besteht kein zusätzliches Risiko einer Token-Wiederverwendung.

11.2. Vorabgenerierung von DPoP-Proofs

Ein Angreifer, der den Client kontrolliert, kann DPoP-Proofs für jeden Zeitpunkt in der Zukunft für einen bestimmten Endpunkt vorab generieren, indem er den iat-Wert im DPoP-Proof wählt, der mit dem Proof-of-Possession-Schlüssel signiert ist. Beachten Sie, dass einer dieser Angreifer der legitime Benutzer des Clients ist. Ein Benutzer könnte DPoP-Proofs vorab generieren, sie von dem Gerät exfiltrieren, das den Proof-of-Possession-Schlüssel besitzt, der sie generiert hat, und sie auf einen anderen Rechner kopieren, der den Schlüssel nicht besitzt. Beispielsweise könnte ein Bankangestellter DPoP-Proofs auf einem Bankcomputer vorab generieren und sie dann auf einen anderen Computer kopieren, um sie später zu verwenden, wodurch die Audit-Kontrollen der Bank umgangen würden. Wenn DPoP-Proofs vorab generiert und exfiltriert werden können, wird in der DPoP-Protokollinteraktion tatsächlich der Besitz des DPoP-Proofs nachgewiesen - und nicht der Besitz des Proof-of-Possession-Schlüssels.

Die Verwendung eines vom Server bereitgestellten Nonce-Wertes, der für den Angreifer unvorhersehbar ist, verhindert diesen Angriff. Durch die Bereitstellung neuer Nonce-Werte zu Zeitpunkten seiner Wahl kann der Server die Lebensdauer von DPoP-Proofs begrenzen und die Verwendung von vorab generierten DPoP-Proofs verhindern. Wenn vom Server bereitgestellte Nonces verwendet werden, ist es der Besitz des Proof-of-Possession-Schlüssels, der nachgewiesen wird - und nicht nur der Besitz des DPoP-Proofs.

Der ath Claim begrenzt die Verwendung vorab generierter DPoP-Proofs auf die Lebensdauer des Zugriffstokens. Bereitstellungen, die den Nonce-Mechanismus nicht verwenden, SOLLTEN KEINE langlebigen DPoP-beschränkten Zugriffstoken ausstellen und stattdessen kurzlebige Zugriffstoken und Refresh-Token bevorzugen. Obwohl ein Angreifer DPoP-Proofs für die Verwendung des Refresh-Tokens zur Erlangung eines neuen Zugriffstokens vorab generieren kann, kann er praktisch keine DPoP-Proofs für die Verwendung des neu ausgestellten Zugriffstokens vorab generieren.

11.3. DPoP-Nonce-Downgrade

Wenn einem Client eine DPoP-Nonce bereitgestellt wurde, DARF der Server KEINE DPoP-Proofs ohne den nonce Claim akzeptieren.

11.4. Nicht vertrauenswürdiger Code im Client-Kontext

Wenn es einem Angreifer gelingt, Code im Ausführungskontext des Clients auszuführen, ist die Sicherheit von DPoP nicht mehr gewährleistet. Häufige Probleme in Webanwendungen, die zur Ausführung von nicht vertrauenswürdigem Code führen, sind XSS und Remote-Code-Inclusion-Angriffe.

Wenn der für DPoP verwendete private Schlüssel so gespeichert ist, dass er nicht exportiert werden kann (z. B. in einem Hardware- oder Software-Sicherheitsmodul), kann der Angreifer den Schlüssel nicht stehlen und ihn zur Erstellung beliebiger DPoP-Proofs verwenden. Der Angreifer kann jedoch neue DPoP-Proofs erstellen, solange der Client online ist, und diese Proofs (zusammen mit den jeweiligen Token) auf dem Gerät des Opfers oder auf einem Gerät unter der Kontrolle des Angreifers verwenden, um beliebige Anforderungen zu senden, die vom Server akzeptiert werden.

Um Anforderungen auch dann zu senden, wenn der Client offline ist, kann der Angreifer versuchen, DPoP-Proofs unter Verwendung zukünftiger Zeitstempel vorzuberechnen und diese Proofs zusammen mit dem Zugriffs- oder Refresh-Token zu exfiltrieren.

Ein Angreifer könnte ferner versuchen, ein von einem Token-Endpunkt ausgegebenes Token mit einem Schlüsselpaar unter der Kontrolle des Angreifers zu verknüpfen. Eine Möglichkeit, dies zu erreichen, besteht darin, vorhandenen Code zu modifizieren, z. B. durch Ersetzen von kryptografischen API-Aufrufen. Eine andere Möglichkeit besteht darin, eine neue Autorisierung zwischen dem Client (in einem iFrame) und dem Autorisierungsserver zu starten. Diese Autorisierung muss "leise" sein, d. h. keine Benutzerinteraktion erfordern. Durch Ausführen von Code im Ursprung des Clients kann der Angreifer auf den resultierenden Autorisierungscode zugreifen und ihn verwenden, um seinen eigenen DPoP-Schlüssel mit dem vom Token-Endpunkt zurückgegebenen Token zu verknüpfen. Der Angreifer kann dann das resultierende Token auf seinem eigenen Gerät verwenden, selbst wenn der Client offline ist.

Daher ist es äußerst wichtig, den Client gegen die Ausführung von nicht vertrauenswürdigem Code zu schützen, auch wenn DPoP verwendet wird. Neben sicheren Programmierpraktiken kann die Content Security Policy (CSP) [W3C.CSP] als zweite Verteidigungsschicht gegen XSS eingesetzt werden.

11.5. Austausch signierter JWTs

Server, die signierte DPoP-Proof-JWTs akzeptieren, MÜSSEN überprüfen, ob das typ Feld in den Headern des JWT dpop+jwt ist, um sicherzustellen, dass keine JWTs, die für andere Zwecke erstellt wurden, von einem Angreifer verwendet werden können.

11.6. Signaturalgorithmen

Implementierer MÜSSEN sicherstellen, dass nur asymmetrische digitale Signaturalgorithmen, die als sicher gelten, wie z. B. ES256, zum Signieren von DPoP-Proofs verwendet werden können. Insbesondere DARF der Algorithmus none NICHT erlaubt sein.

11.7. Anforderungsintegrität

DPoP gewährleistet nicht die Integrität der Payload oder der Header der Anforderung. Der DPoP-Proof enthält nur Claims für die HTTP-URI und Methode, aber nicht z. B. für den Nachrichtentext oder allgemeine Anforderungsheader.

Dies ist eine bewusste Designentscheidung, um DPoP einfach in der Anwendung zu halten, aber wie oben beschrieben, macht dies DPoP anfällig für Replay-Angriffe, bei denen der Angreifer in der Lage ist, den Nachrichteninhalt und die Header zu ändern. In vielen Konfigurationen sind die durch TLS bereitgestellte Nachrichtenintegrität und Vertraulichkeit ausreichend, um ein gutes Schutzniveau zu bieten.

Hinweis: Obwohl Signaturen, die andere Teile der Anforderung abdecken, außerhalb des Geltungsbereichs dieser Spezifikation liegen, können zusätzliche zu signierende Informationen zum DPoP-Proof hinzugefügt werden.

11.8. Bindung von Zugriffstoken und öffentlichem Schlüssel

Die Bindung eines Zugriffstokens an einen öffentlichen DPoP-Schlüssel, die in Abschnitt 6 spezifiziert ist, verwendet einen kryptografischen Hash der JWK-Darstellung des öffentlichen Schlüssels. Sie beruht darauf, dass die Hash-Funktion eine ausreichende Resistenz gegen zweites Urbild (Second-Preimage Resistance) aufweist, so dass es rechnerisch nicht machbar ist, einen anderen Schlüssel zu finden oder zu erstellen, der denselben Hash-Ausgabewert erzeugt. Die Hash-Funktion SHA-256 wurde verwendet, da sie die oben genannte Anforderung erfüllt und gleichzeitig weit verbreitet ist.

Ebenso verwendet die Bindung des DPoP-Proofs an ein Zugriffstoken den Hash dieses Zugriffstokens als Wert des ath Claims im DPoP-Proof (siehe Abschnitt 4.2). Dies beruht darauf, dass der Hash-Wert ausreichend eindeutig ist, um das Zugriffstoken zuverlässig zu identifizieren. Die Kollisionsresistenz von SHA-256 erfüllt diese Anforderung.

11.9. Bindung von Autorisierungscode und öffentlichem Schlüssel

Die kryptografische Bindung des Autorisierungscodes an den öffentlichen DPoP-Schlüssel ist in Abschnitt 10 spezifiziert. Diese Bindung verhindert Angriffe, bei denen der Angreifer den Autorisierungscode abfängt und einen DPoP-Proof unter Verwendung eines anderen Proof-of-Possession-Schlüssels erstellt als dem, der vom Client gehalten wird, und den DPoP-Proof verwendet, um den Autorisierungscode einzulösen. Die End-to-End-Sicherstellung, dass nur der DPoP-Schlüssel des Clients verwendet werden kann, verhindert, dass abgefangene Autorisierungscodes exfiltriert und anderswo verwendet werden als dort, wo der Autorisierungscode ausgestellt wurde.

Autorisierungscodes können von einem Angreifer gesammelt werden, z. B. aus Protokollen, in denen HTTP-Nachrichten aufgezeichnet wurden, die sie enthalten. Selbst wenn Anstrengungen unternommen werden, Autorisierungscodes nur einmal verwendbar zu machen, gibt es in der Praxis oft ein Zeitfenster, in dem ein Angreifer sie erneut abspielen kann. Wenn der Autorisierungsserver beispielsweise als skalierbarer replizierter Dienst implementiert ist, verfügen einige Replikate möglicherweise vorübergehend noch nicht über die Informationen, die erforderlich sind, um die Wiederverwendung zu verhindern. Die DPoP-Bindung des Autorisierungscodes adressiert solche Probleme.

Wenn der Autorisierungsserver die Einmalverwendung für Autorisierungscodes nicht strikt durchsetzt (oder nicht durchsetzen kann) und ein Angreifer Zugriff auf den Autorisierungscode (und den code_verifier, falls PKCE verwendet wird) hat, kann der Angreifer eine gefälschte Token-Anforderung erstellen und das resultierende Token an einen Schlüssel unter der Kontrolle des Angreifers binden. Beispielsweise kann ein Angreifer mittels XSS Zugriff auf den Autorisierungscode und die PKCE-Parameter erhalten. Die Verwendung des dpop_jkt Parameters verhindert diesen Angriff.

Die Bindung des Autorisierungscodes an den öffentlichen DPoP-Schlüssel verwendet den JWK-Thumbprint des öffentlichen Schlüssels, genau wie die Zugriffstoken-Bindung. Es gelten dieselben Überlegungen zum JWK-Thumbprint.

11.10. Agilität des Hash-Algorithmus

Das hier definierte jkt Bestätigungsmethoden-Member, der ath JWT-Claim und der dpop_jkt Autorisierungsanforderungsparameter verwenden alle die Ausgabe der Hash-Funktion SHA-256 als Wert. Die Verwendung einer einzigen Hash-Funktion durch diese Spezifikation ist beabsichtigt und dient der Einfachheit und der Vermeidung potenzieller Sicherheits- und Interoperabilitätsprobleme aufgrund häufiger Fehler bei der Implementierung und Bereitstellung von parametrisierten Algorithmus-Agilitätsmechanismen. Die Verwendung unterschiedlicher Hash-Funktionen ist jedoch nicht ausgeschlossen, sollten sich die Umstände in Zukunft ändern und SHA-256 für die Anforderungen dieser Spezifikation unzureichend machen. Sollte eine solche Anforderung entstehen, wird erwartet, dass eine kurze Spezifikation zur Aktualisierung dieser Spezifikation erstellt wird. Durch Verwendung der Ausgabe einer geeigneten Hash-Funktion als Wert würde diese Spezifikation wahrscheinlich ein neues Bestätigungsmethoden-Member, einen neuen JWT-Claim und einen neuen Autorisierungsanforderungsparameter definieren. Diese würden anstelle oder zusammen mit ihren jeweiligen Gegenstücken in denselben Nachrichtenstrukturen und Abläufen des breiteren Protokolls verwendet, die durch diese Spezifikation definiert sind.

11.11. Bindung an die Client-Identität

Wenn DPoP mit Client-Authentifizierung verwendet wird, ist es nur dadurch an die Authentifizierung gebunden, dass es im selben TLS-Tunnel stattfindet. Da der DPoP-Proof nicht direkt kryptografisch an die Authentifizierung gebunden ist, könnte die Authentifizierung oder die DPoP-Nachricht innerhalb des Tunnels kopiert worden sein. Während die Aufnahme der URI in DPoP dieses Risiko teilweise mindert, könnte ein besserer Schutz geboten werden, indem der Authentifizierungsmechanismus geändert wird, um eine kryptografische Bindung zwischen der Authentifizierung und DPoP bereitzustellen. Die Änderung von Authentifizierungsmechanismen oder die Bereitstellung einer zusätzlichen Bindung an die Authentifizierung durch andere Mittel liegt jedoch außerhalb des Geltungsbereichs dieser Spezifikation.