11. Security Considerations

Dans DPoP, la prévention du rejeu de jeton sur un point de terminaison différent (voir la section 2) est réalisée grâce à l'authentification du serveur selon la [RFC6125] et à la liaison de la preuve DPoP à un certain URI et à une certaine méthode HTTP. Cependant, DPoP présente une nature de protection quelque peu différente des méthodes basées sur TLS telles que OAuth Mutual TLS [RFC8705] ou OAuth Token Binding [TOKEN-BINDING] (voir également les sections 11.1 et 11.7). Les mécanismes basés sur TLS peuvent tirer parti d'une intégration étroite entre la couche TLS et la couche application pour obtenir une intégrité, une authenticité et une protection contre le rejeu du message solides.

11.1. Rejeu de preuve DPoP

Si un adversaire parvient à obtenir un JWT de preuve DPoP, il peut rejouer le jeton sur le même point de terminaison (le point de terminaison et la méthode HTTP sont imposés via les revendications correspondantes dans le JWT). Pour limiter cela, les serveurs DOIVENT n'accepter les preuves DPoP que pendant un temps limité après leur création (de préférence pendant une période relativement brève de l'ordre de quelques secondes ou minutes).

Dans le contexte de l'URI cible, les serveurs peuvent stocker la valeur jti de chaque preuve DPoP pendant la fenêtre de temps où le JWT de preuve DPoP correspondant serait accepté, afin d'empêcher que la même preuve DPoP ne soit utilisée plus d'une fois. Les requêtes HTTP vers le même URI pour lesquelles la valeur jti a été vue précédemment seraient rejetées. Lorsqu'elle est strictement appliquée, une telle vérification à usage unique offre une très forte protection contre le rejeu de preuve DPoP, mais elle n'est pas toujours réalisable en pratique, par exemple lorsque plusieurs serveurs derrière un seul point de terminaison ne partagent pas d'état.

Pour se protéger contre les attaques par épuisement de la mémoire, les serveurs qui suivent les valeurs jti DEVRAIENT rejeter les JWT de preuve DPoP avec des valeurs jti inutilement grandes ou n'en stocker que le hachage.

Remarque : Pour tenir compte de la dérive de l'horloge, le serveur PEUT accepter des preuves DPoP dont l'heure iat se situe raisonnablement dans un futur proche (de l'ordre de quelques secondes ou minutes). Comme la dérive de l'horloge entre le serveur et le client peut être importante, les serveurs PEUVENT limiter la durée de vie des preuves DPoP en utilisant des valeurs de nonce fournies par le serveur contenant l'heure du serveur, au lieu de comparer l'heure iat fournie par le client à l'heure du serveur. Un nonce créé de cette manière produira le même résultat même en présence d'une dérive d'horloge arbitrairement grande.

Les nonces fournis par le serveur sont un moyen efficace de réduire davantage les chances de succès du rejeu de preuve DPoP. Contrairement aux nonces cryptographiques, il est acceptable que le client utilise le même nonce plusieurs fois et que le serveur accepte le même nonce plusieurs fois. Tant que les valeurs jti sont suivies et que les doublons sont rejetés pendant la validité du nonce, il n'y a pas de risque supplémentaire de rejeu de jeton.

11.2. Pré-génération de preuve DPoP

Un attaquant contrôlant le client peut pré-générer des preuves DPoP pour n'importe quel moment dans le futur pour un point de terminaison spécifique en choisissant la valeur iat dans la preuve DPoP signée par la clé de preuve de possession. Notez que l'un de ces attaquants est l'utilisateur légitime du client. Un utilisateur pourrait pré-générer des preuves DPoP, les exfiltrer de la machine possédant la clé de preuve de possession qui les a générées et les copier sur une autre machine ne possédant pas la clé. Par exemple, un employé de banque pourrait pré-générer des preuves DPoP sur un ordinateur de la banque, puis les copier sur une autre machine pour les utiliser ultérieurement, contournant ainsi les contrôles d'audit de la banque. Lorsque les preuves DPoP peuvent être pré-générées et exfiltrées, ce qui est réellement prouvé dans l'interaction du protocole DPoP est la possession de la preuve DPoP - et non la possession de la clé de preuve de possession.

L'utilisation d'une valeur de nonce fournie par le serveur, imprévisible pour l'attaquant, empêche cette attaque. En fournissant de nouvelles valeurs de nonce à des moments de son choix, le serveur peut limiter la durée de vie des preuves DPoP et empêcher l'utilisation de preuves DPoP pré-générées. Lorsque des nonces fournis par le serveur sont utilisés, c'est la possession de la clé de preuve de possession qui est prouvée - et non seulement la possession de la preuve DPoP.

La revendication ath limite l'utilisation de preuves DPoP pré-générées à la durée de vie du jeton d'accès. Les déploiements qui n'utilisent pas le mécanisme de nonce NE DEVRAIENT PAS émettre de jetons d'accès contraints par DPoP à longue durée de vie, et préférer utiliser des jetons d'accès à courte durée de vie et des jetons d'actualisation. Bien qu'un attaquant puisse pré-générer des preuves DPoP pour utiliser le jeton d'actualisation afin d'obtenir un nouveau jeton d'accès, il ne peut pas en pratique pré-générer des preuves DPoP pour utiliser le jeton d'accès nouvellement émis.

11.3. Rétrogradation de nonce DPoP

Lorsqu'un nonce DPoP a été fourni à un client, le serveur NE DOIT accepter aucune preuve DPoP sans la revendication nonce.

11.4. Code non fiable dans le contexte du client

Si un adversaire est capable d'exécuter du code dans le contexte d'exécution du client, la sécurité de DPoP n'est plus garantie. Les problèmes courants dans les applications Web conduisant à l'exécution de code non fiable sont les attaques XSS et d'inclusion de code distant.

Si la clé privée utilisée pour DPoP est stockée de manière à ne pas être exportable (par exemple, dans un module de sécurité matériel ou logiciel), l'attaquant ne peut pas voler la clé et l'utiliser pour créer des preuves DPoP arbitraires. Cependant, l'attaquant peut créer de nouvelles preuves DPoP tant que le client est en ligne et utiliser ces preuves (conjointement avec les jetons respectifs) sur l'appareil de la victime ou sur un appareil sous le contrôle de l'attaquant pour envoyer des requêtes arbitraires qui seront acceptées par le serveur.

Pour envoyer des requêtes même lorsque le client est hors ligne, l'attaquant peut tenter de précalculer des preuves DPoP en utilisant des horodatages futurs et exfiltrer ces preuves avec le jeton d'accès ou d'actualisation.

Un adversaire pourrait en outre tenter d'associer un jeton émis par un point de terminaison de jeton à une paire de clés sous le contrôle de l'attaquant. Une façon d'y parvenir est de modifier le code existant, par exemple en remplaçant les appels API cryptographiques. Une autre façon consiste à lancer une nouvelle autorisation entre le client (dans une iframe) et le serveur d'autorisation. Cette autorisation doit être « silencieuse », c'est-à-dire ne pas nécessiter d'interaction avec l'utilisateur. En exécutant du code dans l'origine du client, l'attaquant peut accéder au code d'autorisation résultant et l'utiliser pour associer sa propre clé DPoP au jeton renvoyé par le point de terminaison de jeton. L'attaquant peut ensuite utiliser le jeton résultant sur son propre appareil, même si le client est hors ligne.

Il est donc extrêmement important de protéger le client contre l'exécution de code non fiable, même si DPoP est utilisé. En plus des pratiques de codage sécurisées, la politique de sécurité du contenu (Content Security Policy - CSP) [W3C.CSP] peut être utilisée comme une deuxième couche de défense contre XSS.

11.5. Échange de JWT signés

Les serveurs acceptant des JWT de preuve DPoP signés DOIVENT vérifier que le champ typ dans les en-têtes du JWT est dpop+jwt pour s'assurer que l'attaquant ne peut pas utiliser de JWT créés à d'autres fins.

11.6. Algorithmes de signature

Les implémenteurs DOIVENT s'assurer que seuls des algorithmes de signature numérique asymétrique jugés sûrs, tels que ES256, peuvent être utilisés pour signer les preuves DPoP. En particulier, l'algorithme none NE DOIT PAS être autorisé.

11.7. Intégrité de la demande

DPoP ne garantit pas l'intégrité de la charge utile ou des en-têtes de la demande. La preuve DPoP contient uniquement des revendications pour l'URI HTTP et la méthode, mais pas, par exemple, le corps du message ou les en-têtes de demande généraux.

Il s'agit d'une décision de conception intentionnelle pour garder DPoP simple à utiliser, mais comme décrit ci-dessus, cela rend DPoP vulnérable aux attaques par rejeu où l'attaquant est capable de modifier le contenu du message et les en-têtes. Dans de nombreuses configurations, l'intégrité et la confidentialité des messages fournies par TLS sont suffisantes pour offrir un bon niveau de protection.

Remarque : Bien que les signatures couvrant d'autres parties de la demande sortent du cadre de cette spécification, des informations supplémentaires à signer peuvent être ajoutées à la preuve DPoP.

11.8. Liaison du jeton d'accès et de la clé publique

La liaison d'un jeton d'accès à une clé publique DPoP, spécifiée à la section 6, utilise un hachage cryptographique de la représentation JWK de la clé publique. Elle repose sur le fait que la fonction de hachage a une résistance suffisante à la seconde préimage, de sorte qu'il est impossible de trouver ou de créer une autre clé produisant la même valeur de sortie de hachage. La fonction de hachage SHA-256 a été utilisée car elle répond à l'exigence mentionnée ci-dessus tout en étant largement disponible.

De même, la liaison de la preuve DPoP à un jeton d'accès utilise le hachage de ce jeton d'accès comme valeur de la revendication ath dans la preuve DPoP (voir la section 4.2). Cela repose sur le fait que la valeur de hachage est suffisamment unique pour identifier de manière fiable le jeton d'accès. La résistance aux collisions de SHA-256 répond à cette exigence.

11.9. Liaison du code d'autorisation et de la clé publique

La liaison cryptographique du code d'autorisation à la clé publique DPoP est spécifiée à la section 10. Cette liaison empêche les attaques dans lesquelles l'attaquant capture le code d'autorisation et crée une preuve DPoP en utilisant une clé de preuve de possession différente de celle détenue par le client, et utilise la preuve DPoP pour échanger le code d'autorisation. Garantir de bout en bout que seule la clé DPoP du client peut être utilisée empêche les codes d'autorisation capturés d'être exfiltrés et utilisés ailleurs qu'à l'endroit où le code d'autorisation a été émis.

Les codes d'autorisation peuvent être collectés par un attaquant, par exemple, à partir de journaux où les messages HTTP les contenant ont été enregistrés. Même si des efforts sont faits pour rendre les codes d'autorisation utilisables une seule fois, en pratique, il existe souvent une fenêtre temporelle pendant laquelle un attaquant peut les rejouer. Par exemple, lorsque le serveur d'autorisation est implémenté sous la forme d'un service répliqué évolutif, certains réplicas peuvent temporairement ne pas encore disposer des informations nécessaires pour empêcher le rejeu. La liaison DPoP du code d'autorisation résout ces problèmes.

Si le serveur d'autorisation n'applique pas strictement (ou ne peut pas appliquer) la restriction d'utilisation unique pour les codes d'autorisation et qu'un attaquant a accès au code d'autorisation (et au code_verifier si PKCE est utilisé), l'attaquant peut créer une fausse demande de jeton, liant le jeton résultant à une clé sous le contrôle de l'attaquant. Par exemple, en utilisant XSS, un attaquant peut avoir accès au code d'autorisation et aux paramètres PKCE. L'utilisation du paramètre dpop_jkt empêche cette attaque.

La liaison du code d'autorisation à la clé publique DPoP utilise l'empreinte JWK de la clé publique, tout comme la liaison du jeton d'accès. Les mêmes considérations relatives à l'empreinte JWK s'appliquent.

11.10. Agilité de l'algorithme de hachage

Le membre de méthode de confirmation jkt, la revendication JWT ath et le paramètre de demande d'autorisation dpop_jkt définis ici utilisent tous la sortie de la fonction de hachage SHA-256 comme valeur. L'utilisation d'une seule fonction de hachage par cette spécification est intentionnelle et vise la simplicité et à éviter les problèmes potentiels de sécurité et d'interopérabilité dus aux erreurs courantes de mise en œuvre et de déploiement des schémas d'agilité d'algorithmes paramétrés. Cependant, l'utilisation de fonctions de hachage différentes n'est pas exclue si les circonstances changent à l'avenir, rendant SHA-256 insuffisant pour les exigences de cette spécification. Si une telle exigence se présentait, on s'attend à ce qu'une courte spécification mettant à jour celle-ci soit produite. En utilisant la sortie d'une fonction de hachage appropriée comme valeur, cette spécification définirait probablement un nouveau membre de méthode de confirmation, une nouvelle revendication JWT et un nouveau paramètre de demande d'autorisation. Ces éléments seraient utilisés à la place ou avec leurs homologues respectifs dans les mêmes structures de message et flux du protocole plus large défini par cette spécification.

11.11. Liaison à l'identité du client

Lorsque DPoP est utilisé avec l'authentification du client, il n'est lié à l'authentification que par le fait qu'il se produit dans le même tunnel TLS. Comme la preuve DPoP n'est pas directement liée cryptographiquement à l'authentification, l'authentification ou le message DPoP pourraient avoir été copiés dans le tunnel. Bien que l'inclusion de l'URI dans DPoP atténue ce risque en partie, une meilleure protection pourrait être fournie en modifiant le mécanisme d'authentification pour fournir une liaison cryptographique entre l'authentification et DPoP. Cependant, la modification des mécanismes d'authentification ou la fourniture d'une liaison supplémentaire avec l'authentification par d'autres moyens sortent du cadre de cette spécification.