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 à restaurer l’état

Les protocoles d’autorisation fournissent un paramètre state qui vous permet de restaurer l’état antérieur de votre application. Le paramètre state conserve certains objets d’état définis par l’application dans la requête d’autorisation et les rend accessibles à l’application 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 demande d’authentification avant qu’elle soit lancée. Cette valeur vous permet de prévenir l’attaque en confirmant que la valeur renvoyée dans la réponse correspond à celle que vous avez envoyée.

Le paramètre state est une chaîne de caractères; vous pouvez donc y encoder toute autre information. Vous envoyez une valeur aléatoire au moment de lancer une demande 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, un élément (dans des témoins, la session ou le stockage local) qui vous permet d’effectuer cette validation. Si vous recevez une réponse avec une valeur state qui ne correspond pas, vous pouvez en déduire que vous êtes peut-être la cible d’une attaque, car il s’agit soit d’une réponse à une demande 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 faire correspondre la demande à la réponse reçue lors de l’authentification.

La plupart des SDK OIDC modernes et des SDK OAuth, y compris Auth0.js dans les applications à page unique, gèrent automatiquement la génération et la validation de la valeur 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 en sorte que l’application génère une chaîne aléatoire. Par exemple :

   xyzABC123
   

   La longueur autorisée 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 (avec encodage URL au besoin). Par exemple :

   // Encoder la chaîne   
   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, acceptez la réponse d’authentification; sinon, refusez-la.

   // Décoder la chaîne
   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 un état de l’application afin de ramener l’utilisateur là où il se trouvait avant le début du processus d’authentification. Par exemple, si un utilisateur tente d’accéder à une page protégée dans votre application et que cette action déclenche une demande d’authentification, vous pouvez stocker cette URL afin de rediriger l’utilisateur vers la page souhaitée une fois l’authentification terminée.

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

​

Utilisez l’URL enregistrée pour rediriger les utilisateurs

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

2. Enregistrez le nonce localement en l’utilisant comme clé pour stocker toutes les autres informations d’état de l’application, comme l’URL vers laquelle l’utilisateur voulait accéder. Par exemple :

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

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

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

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

​

Méthode de redirection alternative

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

​

Limitations et considérations

• Choisissez une méthode de stockage en fonction du type d’application.

Type d’application	Recommandation de stockage
Application Web classique	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 modifier. Cela s’applique également à 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.

• Le passage d’URL en texte brut ou de toute autre 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 dois-je utiliser ?
• Sessions