Prévenir les attaques et rediriger les utilisateurs avec les paramètres `state` d’OAuth 2.0

Décrit comment utiliser le paramètre state dans les requêtes d’authentification pour aider à prévenir les attaques CSRF et à rétablir l’état

Les protocoles d’autorisation fournissent un paramètre state qui vous permet de rétablir l’état précédent de votre application. Le paramètre state conserve certains objets d’état définis par le client dans la requête d’autorisation et les rend accessibles au client dans la réponse.

​

Attaques CSRF

La principale raison d’utiliser le paramètre state est d’atténuer les attaques CSRF en utilisant une valeur unique et impossible à deviner, associée à chaque requête d’authentification sur le point d’être lancée. Cette valeur vous permet de prévenir l’attaque en confirmant que la valeur renvoyée dans la réponse correspond bien à celle que vous avez envoyée.

Le paramètre state est une chaîne de caractères, ce qui vous permet d’y encoder toute autre information. Vous envoyez une valeur aléatoire au moment de lancer une requête d’authentification et vous validez la valeur reçue lors du traitement de la réponse. Vous stockez ensuite, du côté de l’application cliente, un élément (dans des cookies, la session ou le localstorage) qui vous permet d’effectuer cette validation. Si vous recevez une réponse dont la valeur state ne correspond pas, vous pouvez en déduire que vous êtes peut-être la cible d’une attaque, puisqu’il s’agit soit d’une réponse à une requête non sollicitée, soit d’une tentative de falsification de la réponse.

Une attaque CSRF cible précisément les requêtes qui modifient l’état afin de déclencher une action plutôt que d’obtenir des données utilisateur, parce que l’attaquant n’a aucun moyen de voir la réponse à la requête falsifiée. Dans les cas les plus simples, le paramètre state devrait être un nonce, utilisé pour corréler la requête avec la réponse reçue lors de l’authentification.

La plupart des SDK OIDC et OAuth modernes, y compris Auth0.js dans les applications monopages, gèrent automatiquement la génération et la validation du paramètre state.

​

Définir et comparer les valeurs du paramètre state

1. Avant de rediriger une requête vers le fournisseur d’identité (IdP), faites générer une chaîne aléatoire par l’application. Par exemple :

   xyzABC123
   

   La longueur permise pour state n’est pas illimitée. Si vous obtenez l’erreur 414 Request-URI Too Large, essayez une valeur plus courte.

2. Stockez la chaîne localement. Par exemple :

   storeStateLocally(xyzABC123)
   

3. Ajoutez le paramètre state à la requête (en encodant l’URL au besoin). Par exemple :

   // Encoder le String   
   tenant.auth0.com/authorize?...&state=xyzABC123
   

   Une fois la requête envoyée, Auth0 redirige l’utilisateur vers l’application. La valeur state sera incluse dans cette redirection. Notez que, selon le type de connexion utilisé, cette valeur peut se trouver dans le corps de la requête ou dans la chaîne de requête.

   /callback?...&state=xyzABC123
   

4. Récupérez la valeur state renvoyée et comparez-la à celle que vous avez stockée précédemment. Si les valeurs correspondent, approuvez la réponse d’authentification; sinon, rejetez-la.

   // Décoder le String
   var decodedString = Base64.decode(encodedString);
   if(receivedState === retrieveStateStoredLocally()) {
    // Requête autorisée
   } 
   else {
     // Cette réponse ne nous est pas destinée, rejetez-la
   }
   

​

Rediriger les utilisateurs

Vous pouvez utiliser le paramètre state pour encoder l’état de l’application et ramener l’utilisateur à l’endroit où il se trouvait avant le début du processus d’authentification. Par exemple, si un utilisateur essaie d’accéder à une page protégée de votre application et que cette action déclenche la requête d’authentification, vous pouvez stocker cette URL afin de le rediriger vers la page qu’il voulait consulter une fois l’authentification terminée.

Générez et stockez localement un nonce (dans des cookies, la session ou le stockage local) avec les données d’état voulues, comme l’URL de redirection. Utilisez le nonce comme valeur de state dans le message du protocole. Si l’état renvoyé correspond au nonce stocké, acceptez le message OAuth2 et récupérez les données d’état correspondantes à partir du stockage. C’est l’approche que nous utilisons dans auth0.js.

​

Utiliser l’URL stockée pour rediriger les utilisateurs

1. Définissez la valeur du paramètre state nonce que vous avez utilisée pour atténuer les attaques CSRF, comme expliqué ci-dessus.

2. Stockez le nonce localement, en l’utilisant comme clé pour stocker toutes les autres informations sur l’état de l’application, comme l’URL vers laquelle l’utilisateur souhaitait se rendre. Par exemple :

   {
     "xyzABC123" : {
       redirectUrl: '/protectedResource',
       expiresOn: [...]
     }
   }
   

3. Authentifiez l’utilisateur, en envoyant le nonce généré comme state.

4. Dans le cadre du traitement du callback et de la validation de la réponse, vérifiez que le state renvoyé correspond au nonce stocké localement. Si c’est le cas, récupérez le reste de l’état de l’application (comme le redirectUrl).

5. Une fois le traitement du callback terminé, redirigez l’utilisateur vers l’URL stockée précédemment.

​

Méthode de redirection alternative

1. Générez et stockez localement une valeur nonce.
2. Encodez tout state souhaité (comme l’URL de redirection) avec le nonce dans un message protégé (qui devra être chiffré/signé pour éviter toute falsification).
3. Lors du traitement de la réponse, retirez la protection du message afin de récupérer le nonce et les autres propriétés stockées.
4. Validez que le nonce inclus correspond à celui stocké localement et, si c’est le cas, acceptez le message OAuth2.

​

Limitations et considérations

• Choisissez une méthode de stockage selon votre type d’application.

Type d’application	Recommandation de stockage
Application Web traditionnelle	Cookie ou session
SPA	Stockage local du navigateur
Application native	Mémoire ou stockage local

• Du point de vue de la sécurité, ni la requête ni la réponse ne sont protégées par un mécanisme d’intégrité; un utilisateur peut donc les manipuler. Cela vaut aussi pour l’ajout d’un paramètre à redirect_uri.

• La longueur autorisée pour la valeur du paramètre state n’est pas illimitée. Si vous obtenez l’erreur 414 Request-URI Too Large, essayez une valeur plus courte.

• Transmettre des URL en texte brut ou de façon prévisible n’est pas sécuritaire. Assurez-vous que la valeur du paramètre state est :

  • Unique et opaque afin de pouvoir servir de protection contre les attaques CSRF et d’hameçonnage.
  • Si elle est stockée dans un cookie, elle doit être signée pour empêcher toute falsification.

​

En savoir plus

• Quel flux OAuth 2.0 devrais-je utiliser ?
• Sessions