Meilleures pratiques en lien aux règles de sécurité

Dans le cadre de l’implémentation de vos règles, utilisez toujours HTTPS, et non HTTP, en effectuant des appels vers des services externes ou lors de l’exécution d’une redirection.

Les informations sensibles en matière de sécurité, telles que les informations concernant l’identification ou les clés API, doivent être stockées dans les paramètres de votre règle où elles seront masquées, chiffrées et disponibles via l’objet configuration. Ne stockez pas ces valeurs sous forme de littéraux dans votre code de règles. Par exemple, n’écrivez pas de code comme celui-ci :

const myApiKey = ’abc123’;

Optez plutôt pour stocker les informations (confidentielles) afin qu’elles soient accessibles par le biais de l’objet configuration :

const myApiKey = configuration.myApiKey;

Pour les règles concernant l’envoie d’informations à un service externe, assurez-vous de ne pas envoyer la totalité de l’objet contexte, car cet objet peut contenir des jetons ou d’autres données confidentielles. Pour les règles concernant l’envoie d’informations à des services externes, vous ne devez envoyer qu’un sous-ensemble des attributs les moins confidentiels de l’objet context quand cela est nécessaire.

De la même manière, évitez de transmettre tout aspect de l’objet auth0 à l’extérieur d’une règle.

Vous pouvez vérifier si l’adresse courriel d’un utilisateur est vérifiée dans une règle :

function (user, context, callback) {
      // Access should only be granted to verified users.
      if (!user.email || !user.email_verified) {
    return callback(new UnauthorizedError('Access denied.'));
      }
    	  .
    	  .
    }

Toutefois, si vous voulez exécuter un code différent selon l’entreprise à laquelle appartient l’utilisateur, ne vous fiez au domaine de messagerie, mais plutôt aux données qui peuvent relier l’utilisateur au fournisseur d’identité auprès duquel il s’est authentifié (la connexion ou les champs propres au fournisseurs d’identités tels que letenant id d’Azure).

Pour les règles qui déterminent le contrôle d’accès en fonction d’une chaîne particulière, telle qu’un domaine de messagerie, recherchez une correspondance exacte de la chaîne plutôt que de rechercher une correspondance de sous-chaîne. Si vous recherchez uniquement une sous-chaîne, votre règle risque de ne pas fonctionner comme prévu. Par exemple, dans :

if( _.findIndex(connection.options.domain_aliases, function(d){ return user.email.indexOf(d) >= 0;

le code (ci-dessus) retournerait true pour des courriels comme :

• user.domain.com@not-domain.com

• "user@domain.com"@not-domain.com (guillemets inclus)

ce qui n’est peut-être pas souhaité. Optez plutôt pour des correspondances exactes en utilisant un code tel que :

const emailSplit = user.email.split(’@’); const userEmailDomain = emailSplit[emailSplit.length - 1].toLowerCase();

Pour en apprendre davantage, consultez Vérifier si le domaine de courriel de l’utilisateur correspond au modèle de règle de domaine configuré sur GitHub, ou naviguez vers Auth0 Dashboard > Pipeline d’Auth > Régles, et sélectionnez Créer.

L’authentification multifacteur (MFA) fournit une couche de sécurité supplémentaire pour protéger contre les accès non autorisés. Du point de vue de l’expérience utilisateur, cela nécessite généralement une interaction utilisateur de plus pour fournir un deuxième facteur d’authentification, c’est-à-dire présenter des identifiants supplémentaires ou autoriser une certaine forme de demande d’accès.

Il existe toutefois des cas dans lesquels il peut être souhaitable de contourner la MFA pour un utilisateur désigné comme nécessitant une authentification multifacteur (MFA). Par exemple, il peut être souhaitable de contourner la MFA si un utilisateur a déjà présenté des facteurs primaires et secondaires à titre d’authentification dans le contexte actuel du navigateur. Cette vérification contextuelle peut contribuer à améliorer l’expérience utilisateur. Toutefois, si cela n’est pas bien fait, de graves failles de sécurité peuvent surgir, ce qui pourraient ultérieurement entraîner des violations en terme de sécurité en raison du non-respect de la MFA. Nous vous recommandons donc de respecter les conseils suivants lorsque vous décidez d’utiliser ou non le contournement contextuel de la MFA.

En tant que meilleure pratique, l’utilisation de allowRememberBrowser ou de context.authentication doit être la seule option prise en compte pour le contournement contextuel lors de l’utilisation de la MFA prête à l’emploi. Régler allowRememberBrowser sur true permet aux utilisateurs de cocher une case afin qu’ils ne soient invités à effectuer la MFA que périodiquement, tandis que context.authentication peut être utilisé en toute sécurité et avec précision pour déterminer quand la MFA a été effectuée pour la dernière fois dans le contexte actuel du navigateur; vous pouvez voir un exemple d’utilisation de context.authentication dans la règle fournie prête à l’emploi, Exiger MFA une fois par session.

• N’effectuez pas de contournement MFA basé sur une logique conditionnelle liée à l’authentification silencieuse (p. ex., context.request.query.prompt === ’none’)

• N’effectuez pas de contournement MFA basé sur une logique conditionnelle utilisant une certaine forme d’empreinte digitale de l’appareil (p. ex., où user.app_metadata.lastLoginDeviceFingerPrint === deviceFingerPrint)

• N’effectuez pas de contournement MFA basé sur une logique conditionnelle liée à l’emplacement géographique (p. ex., où user.app_metadata.last_location === context.request.geoip.country_code)

Tout comme nous l’avons fait auparavant, nous vous recommandons de suivre les conseils fournis dans les éléments répertoriés ci-dessus pour toutes les règles qui redirigent les utilisateurs vers des fournisseurs de authentification multifacteur (MFA) personnalisés. Par exemple, pour les fournisseurs personnalisés, il n’existe aucun moyen sûr de contourner efficacement la MFA lors d’une authentification silencieuse, car la redirection (requise pour la MFA personnalisée) échouera toujours dans les situations d’authentification silencieuse.

• Meilleures pratiques concernant l’anatomie des règles
• Meilleures pratiques de l’environnement des règles
• Meilleures pratiques d’exécution des règles
• Meilleures pratiques de test des règles
• Sécuriser