1. Introduction

Les clients publics OAuth 2.0 [RFC6749] sont sensibles à l'attaque d'interception du code d'autorisation (Authorization Code Interception Attack).

Dans cette attaque, l'attaquant intercepte le code d'autorisation retourné par le point de terminaison d'autorisation dans un chemin de communication non protégé par Transport Layer Security (TLS), comme la communication inter-application au sein du système d'exploitation du client.

Une fois que l'attaquant a obtenu l'accès au code d'autorisation, il peut l'utiliser pour obtenir le jeton d'accès (Access Token).

La figure 1 montre l'attaque graphiquement. À l'étape (1), l'application native s'exécutant sur le terminal (comme un smartphone) émet une demande d'autorisation OAuth 2.0 via le navigateur/système d'exploitation. L'URI du point de terminaison de redirection utilise généralement un schéma URI personnalisé (Custom URI Scheme) dans ce cas. L'étape (1) se déroule via une API sécurisée qui ne peut pas être interceptée, bien qu'elle puisse potentiellement être observée dans des scénarios d'attaque avancés. La demande est ensuite transmise au serveur d'autorisation OAuth 2.0 à l'étape (2). Puisque OAuth exige l'utilisation de TLS, cette communication est protégée par TLS et ne peut pas être interceptée. Le serveur d'autorisation retourne le code d'autorisation à l'étape (3). À l'étape (4), le code d'autorisation est retourné au demandeur via l'URI du point de terminaison de redirection fourni à l'étape (1).

Notez qu'il est possible pour une application malveillante de s'enregistrer comme gestionnaire pour le schéma personnalisé en plus de l'application OAuth 2.0 légitime. Une fois qu'elle a fait cela, l'application malveillante peut maintenant intercepter le code d'autorisation à l'étape (4). Cela permet à l'attaquant de demander et d'obtenir un jeton d'accès aux étapes (5) et (6), respectivement.

Un certain nombre de conditions préalables doivent être remplies pour que cette attaque fonctionne :

1. L'attaquant parvient à enregistrer une application malveillante sur l'appareil client et enregistre un schéma URI personnalisé également utilisé par une autre application. Le système d'exploitation doit permettre à plusieurs applications d'enregistrer le même schéma URI personnalisé.

2. L'octroi de code d'autorisation OAuth 2.0 est utilisé.

3. L'attaquant a accès au client_id et au client_secret OAuth 2.0 [RFC6749] (si provisionné). Toutes les instances de client d'application native OAuth 2.0 utilisent le même client_id. Les secrets provisionnés dans les applications binaires client ne peuvent pas être considérés comme confidentiels.

4. L'une des conditions suivantes est remplie :

   4a. L'attaquant (via l'application installée) n'est capable d'observer que les réponses du point de terminaison d'autorisation. Lorsque la valeur code_challenge_method est plain, seule cette attaque est atténuée.

   4b. Un scénario d'attaque plus sophistiqué permet à l'attaquant d'observer les demandes (en plus des réponses) au point de terminaison d'autorisation. L'attaquant n'est cependant pas capable d'agir comme un homme du milieu (Man-in-the-Middle). Cela a été causé par la fuite d'informations de journal HTTP dans le système d'exploitation. Pour atténuer cela, la valeur code_challenge_method doit être définie sur S256 ou une valeur définie par une extension code_challenge_method cryptographiquement sécurisée.

Bien qu'il s'agisse d'une longue liste de conditions préalables, l'attaque décrite a été observée dans la nature et doit être prise en compte dans les déploiements OAuth 2.0.

Pour atténuer cette attaque, cette extension utilise une clé aléatoire cryptographique créée dynamiquement appelée "vérificateur de code" (code verifier). Un vérificateur de code unique est créé pour chaque demande d'autorisation, et sa valeur transformée, appelée "défi de code" (code challenge), est envoyée au serveur d'autorisation pour obtenir le code d'autorisation. Le code d'autorisation obtenu est ensuite envoyé au point de terminaison de jeton avec le "vérificateur de code", et le serveur le compare avec le code de demande précédemment reçu afin que le client puisse effectuer la preuve de possession du "vérificateur de code". Cela fonctionne comme atténuation car l'attaquant ne connaîtrait pas cette clé à usage unique, car elle est envoyée via TLS et ne peut pas être interceptée.

1.1 Flux du protocole

Ce document ajoute des paramètres supplémentaires aux demandes d'autorisation et de jeton d'accès OAuth 2.0.

A. Le client crée et enregistre un secret nommé "code_verifier" et dérive sa version transformée "t(code_verifier)" (appelé "code_challenge"), qui est envoyé dans la demande d'autorisation OAuth 2.0 avec la méthode de transformation "t_m".

B. Le point de terminaison d'autorisation répond comme d'habitude mais enregistre "t(code_verifier)" et la méthode de transformation.

C. Le client envoie ensuite le code d'autorisation dans la demande de jeton d'accès comme d'habitude mais inclut le secret "code_verifier" généré en (A).

D. Le serveur d'autorisation transforme "code_verifier" et le compare à "t(code_verifier)" de (B). L'accès est refusé s'ils ne sont pas égaux.

Un attaquant qui intercepte le code d'autorisation en (B) est incapable de l'échanger contre un jeton d'accès, car il n'est pas en possession du secret "code_verifier".

---