Authentification et autorisation
Le sujet de l'authentification (AuthN) et de l'autorisation (AuthZ) est crucial en raison de la fréquence des vulnérabilités qui les touchent. Leur récurrence témoigne souvent d'une certaine confusion quant à leur définition ou aux causes de leurs failles.
Pour rappel, chaque terme recouvre les aspects 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 ou un point de terminaison spécifique
- Le manque de protection contre les attaques par force brute (bourrage d'identifiants)
- Des processus de récupération de compte/mot de passe non sécurisés
- Une génération, validation, expiration, transmission ou stockage non sécurisés des jetons d'authentification
- Une validation incorrecte ou manquante de l'authentification à deux facteurs (2FA) de l'utilisateur (le cas échéant)
Le premier point de la liste (absence d'authentification) est de loin le problème le plus fréquemment observé. Il arrive souvent qu'un développeur doive annoter ou configurer explicitement le niveau d'authentification requis pour une page ou un point de terminaison, une étape facile à oublier.
Il est recommandé de s'assurer qu'un système échoue par défaut en mode fermé, plutôt qu'en mode ouvert. Ainsi, au lieu d'annoter chaque point de terminaison pour exiger une session utilisateur authentifiée, la règle par défaut devrait être que toutes les routes nécessitent une session utilisateur authentifiée, sauf exception spécifique. Cela permet de réduire considérablement les risques d'erreur.
Autorisation (contrôle d'accès défaillant)
Les problèmes d'autorisation se manifestent couramment de plusieurs manières :
- Références directes non sécurisées à des objets (IDOR)
- Contrôle d'accès aux fonctions manquant (AuthZ manquante)
- Élévation de privilèges (horizontale ou verticale)
Références directes non sécurisées à des objets
Les objets possèdent généralement des identifiants uniques (ID) utilisés comme clés de référence. Lorsqu'un utilisateur envoie une requête pour consulter une commande, un compte ou autre, celle-ci contient souvent cet ID. Une « référence directe non sécurisée à un objet » survient lorsque l'application omet de vérifier si l'utilisateur est autorisé à accéder à cet objet spécifique.
Contrôle d'accès aux 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é, les développeurs doivent souvent vérifier l'autorisation dans le gestionnaire ou annoter le point de terminaison pour spécifier les exigences nécessaires à son appel.
Malheureusement, ces étapes supplémentaires sont également très faciles à oublier, ce qui explique souvent l'apparition de certaines vulnérabilités liées à l'autorisation.
Recommandations
Privilégier une approche fermée par défaut
En matière d'authentification comme d'autorisation, il est crucial de privilégier une approche fermée par défaut plutôt qu'ouverte.
Selon votre langage ou framework, il est recommandé de configurer toutes les routes de votre application pour exiger par défaut une session authentifiée avec les rôles ou permissions les plus élevés. Cela oblige le développeur à modifier explicitement ces exigences pour chaque route.
cs
// S'assurer que le comportement par défaut authentifie les requêtes et vérifie les droits d'administrateur
[Authenticate]
[Authorize("Admin")]
public class SecureController : Controller
{
}
public class MyController : SecureController
{
// Remplace l'attribut Authorize hérité pour permettre à tout utilisateur d'accéder à la page
[Authorize("User")]
public Page ShowUserProfile() {
}
// Accessible uniquement par un administrateur
public Page ShowAdminPage() {
}
// Remplace les attributs Authenticate et Authorize pour m'autoriser
[AllowAnonymous]
public Page ShowLoginPage() {
}
}
Appliquer les contrôles d'autorisation dans les services
Lors de l'accès aux données, il est primordial de garantir que tous les accès appliquent les contrôles de sécurité et d'autorisation pertinents de manière uniforme. Cela s'obtient généralement par l'utilisation de services de domaine.
Autres exemples
Below, we’ve got a short collection of examples that give a good look at the difference between secure and insecure authentication and authorization.
C# - non sécurisé
Authentification manquante
public class AdminController : Controller
{
// NON SÉCURISÉ : Aucune vérification de connexion avant d'afficher une page d'administration
public Page ShowAdminPage() {
}
}
Autorisation manquante
[Authenticate]
public class AdminController : Controller
{
// NON SÉCURISÉ : Aucune vérification des droits d'accès avant d'afficher une page d'administration public Page ShowAdminPage() {
}
}
C# - sécurisé
[Authenticate]
[Authorize("Admin")]
public class AdminController : Controller
{
// SÉCURISÉ : Vérifie à la fois que l'utilisateur est connecté et possède le rôle Administrateur
public Page ShowAdminPage() {
}
}
Le codage sécurisé en pratique
Explorez nos directives de développement sécurisé pour comprendre et atténuer les vulnérabilités logicielles telles que l'OWASP Top 10, et plongez dans des missions de formation guidées pour vous exercer sur des simulations d'applications réelles.