Authentification et autorisation
Le sujet de l'authentification (AuthN) et de l'autorisation (AuthZ) est extrêmement important en raison de la fréquence des vulnérabilités impliquant la vulnérabilité de l'une ou l'autre d'entre elles. Comme ils semblent apparaître si régulièrement, cela signifie généralement qu'il existe une certaine incertitude quant à leur nature ou même à leurs causes.
Pour rappel, chaque terme couvre les éléments suivants :
- Authentification : qui est l'utilisateur ?
- Autorisation : à quoi l'utilisateur doit-il avoir accès ?
Nous les examinerons séparément ci-dessous.
Authentification (échecs d'identification et d'authentification)
Une authentification incorrecte peut couvrir une grande variété de vulnérabilités, telles que :
- L'absence d'authentification sur une page/un point de terminaison spécifique
- Absence de protection contre les attaques par force brute (bourrage d'informations d'identification)
- Processus de récupération de compte/mot de passe non sécurisés
- Génération, validation, expiration, transmission ou stockage de jetons d'authentification non sécurisés
- Validation incorrecte ou manquante indiquant que l'utilisateur s'est authentifié à l'aide de la 2FA (le cas échéant)
Le premier élément de la liste (absence d'authentification) est de loin le problème le plus fréquemment observé dans la nature. Souvent, un développeur devra explicitement annoter ou configurer le niveau d'authentification devant être requis par une page ou un point de terminaison et cette étape risque facilement d'être manquée.
Il s'agit d'une bonne pratique pour garantir la défaillance d'un système fermé, plutôt que de s'ouvrir en panne. Ainsi, plutôt que d'annoter chaque point de terminaison avec les informations indiquant qu'il nécessite une session utilisateur authentifiée, la valeur par défaut devrait être tous les itinéraires nécessitent une session utilisateur authentifiée à moins qu'elle n'ait été spécifiquement remplacée. Cela peut réduire considérablement le risque d'erreur.
Autorisation (contrôle d'accès non fonctionnel)
Les problèmes d'autorisation peuvent se présenter de différentes manières, ce qui est très courant :
- Références directes à des objets non sécurisées (IDOR)
- Contrôle d'accès au niveau des fonctions manquant (AuthZ manquant)
- Escalade de privilèges (horizontale ou verticale)
Références directes à des objets non sécurisées
Les objets ont tendance à avoir des identificateurs uniques (ID) qui sont utilisés comme clé pour les référencer. Lorsqu'un utilisateur envoie une demande pour consulter une commande, un compte ou quelque chose de similaire, il contient généralement cet identifiant. Une « référence directe à un objet non sécurisée » se produit lorsque l'application ne parvient pas à valider si l'utilisateur doit (ou non) être en mesure d'accéder à cet objet spécifique.
Contrôle d'accès au niveau des fonctions manquant
Une autre vulnérabilité très courante est l'absence de contrôles d'autorisation pour une page ou un point de terminaison (par opposition à un objet).
Selon le framework utilisé, il est courant que les développeurs doivent soit vérifier l'autorisation dans le gestionnaire, soit annoter le point de terminaison et spécifier les exigences requises pour appeler le point de terminaison.
Malheureusement, ces étapes supplémentaires sont également très faciles à oublier, ce qui explique souvent comment certaines vulnérabilités d'autorisation finissent par se produire.
Recommandations
Par défaut, fermé au lieu d'ouvrir
Dans le cas de l'authentification et de l'autorisation, le principe consistant à passer par défaut à fermé au lieu d'ouvert est important.
En fonction de votre langage/framework, il est recommandé de s'assurer que la valeur par défaut pour toutes les routes de votre application nécessite une session authentifiée avec les rôles ou les autorisations les plus élevés possibles. Cela oblige le développeur à ignorer les exigences relatives à l'itinéraire.
cs
//Assurez-vous que le comportement par défaut est d'authentifier les demandes et de vérifier si elles sont d'origine administrative
[Authentifier]
[Autoriser (« Admin »)]
classe publique SecureController : Controller
{
}
classe publique MyController : SecureController
{
//Remplace l'attribut Authorize hérité pour permettre à n'importe quel utilisateur d'accéder à la page
[Autoriser (« Utilisateur »)]
page publique ShowUserProfile () {
}
//Accessible uniquement à un utilisateur administrateur
page publique ShowAdminPage () {
}
//Remplace l'attribut Authenticate and Authorize pour m'autoriser
[Autoriser l'anonymat]
page publique ShowLoginPage () {
}
}
Appliquer les contrôles d'autorisation dans les services
Lors de l'accès aux données, il est extrêmement important de s'assurer que tous les accès aux données appliquent des contrôles d'accès et d'autorisation pertinents de manière uniforme. Ceci est généralement réalisé grâce à l'utilisation d'un service de domaine.
D'autres exemples
Vous trouverez ci-dessous une courte collection d'exemples qui donnent un bon aperçu de la différence entre une authentification et une autorisation sécurisées et non sécurisées.
C# - non sécurisé
Authentification manquante
classe publique AdminController : Controller
{
//NON SÉCURISÉ : ne vérifie pas si l'utilisateur est connecté avant d'afficher une page d'administration
page publique ShowAdminPage () {
}
}
Autorisation manquante