Série OWASP Top 10 API : Les développeurs face à la sécurité - Authentification défaillante

Il n'est pas surprenant que l'authentification défaillante figure sur la liste OWASP des problèmes liés aux API : les mécanismes d'authentification sont notoirement difficiles à implémenter correctement. De plus, les attaquants bénéficient d'un certain avantage car, par nature, la plupart des défis d'authentification doivent être exposés aux utilisateurs, ce qui donne aux attaquants l'occasion de les étudier et de rechercher des modèles ou des vulnérabilités qu'ils peuvent exploiter.

Enfin, comme l'authentification sert souvent de passerelle vers une application et, potentiellement, vers le reste d'un réseau, elle constitue une cible de choix pour les attaquants. Si un processus d'authentification est défaillant ou vulnérable, il y a de fortes chances que les attaquants découvrent cette faille et l'exploitent.

Dans ce chapitre, nous allons apprendre à bloquer les pirates en ce qui concerne les problèmes d'authentification. Si vous souhaitez d'abord tester vos compétences, lancez-vous dans notre défi ludique :

Vous voulez améliorer votre score ? Restez avec moi pendant que nous analysons tout cela.

Quels sont quelques exemples d'authentification défaillante ou mal configurée ?

Un exemple où le problème n'est peut-être pas si évident survient lorsqu'une méthode d'authentification est vulnérable au « credential stuffing », c'est-à-dire l'utilisation de listes de noms d'utilisateur et de mots de passe connus pour contourner la sécurité. Même une méthode d'autorisation normalement très sécurisée, comme l'authentification multifacteur, peut être vulnérable si les requêtes ne sont pas limitées, restreintes ou surveillées d'une autre manière.

Par exemple, un attaquant pourrait déclencher une demande de récupération de mot de passe en envoyant une requête POST à api/system/verification-codes et en fournissant un nom d'utilisateur dans le corps de la requête. Si une application utilise un défi par SMS où un code à six chiffres est envoyé sur le téléphone de l'utilisateur, mais que le champ de saisie n'est pas limité, l'application peut être piratée en quelques minutes seulement. Il suffit à l'attaquant d'envoyer toutes les combinaisons possibles à six chiffres jusqu'à ce qu'il trouve la bonne.

Dans ce scénario, en apparence, l'utilisation de l'authentification à deux facteurs semble protéger l'application. Mais comme la saisie de l'utilisateur n'est pas limitée en débit, l'authentification est défaillante et vulnérable.

Dans un autre exemple, une application pourrait utiliser des objets utilisateur encodés comme cookies d'authentification. Mais si un attaquant disposant d'un accès utilisateur de bas niveau décode ce cookie en utilisant Base64, il pourrait découvrir comment le cookie définit les sessions et les utilisateurs pour l'application. Par exemple, il pourrait voir le JSON suivant une fois décodé :

{
"username" : "ShadyGuy",
"role" : "user"
{

À ce stade, l'utilisateur malveillant pourrait modifier son nom d'utilisateur, son rôle, ou les deux. Il pourrait devenir un autre utilisateur avec un niveau de privilège plus élevé en modifiant quelques valeurs :

{
"username" : "GoodGuy",
"role" : "admin"
{

À ce stade, si l'attaquant réencode les informations et les définit comme valeur de cookie, il devient essentiellement le nouvel utilisateur avec un niveau de permission plus élevé. À moins que des méthodes ne soient en place pour empêcher une telle modification, il y a de fortes chances que l'application accepte la transformation.

Éliminer l'authentification défaillante ou mal configurée

Si l'authentification échoue, il y a de fortes chances que la sécurité globale soit compromise. Mais suivre quelques directives importantes lors du codage des applications peut aider à tout sécuriser.

Tout d'abord, assurez-vous d'inclure des contrôles d'authentification partout où les utilisateurs peuvent accéder aux fonctionnalités du programme. Si le contrôle d'authentification est totalement absent, la bataille est perdue d'avance.

En termes de bonnes pratiques, il est utile de garder à l'esprit qu'il faut éviter d'exposer les identifiants de session dans l'URL accessible aux utilisateurs. Dans le deuxième exemple ci-dessus concernant l'authentification défaillante, empêcher un attaquant d'essayer de décoder le cookie de session est beaucoup plus facile s'il ne lui est jamais exposé.

Il est également judicieux de mettre en place une authentification multifacteur. Cela peut être réalisé de manière sécurisée à l'aide de jetons matériels qui génèrent des mots de passe algorithmiques à intervalles réguliers. Si vous ne pouvez pas fournir de tels appareils à vos utilisateurs, les SMS sont une alternative possible. Veillez toutefois à limiter les tentatives à un nombre raisonnable, par exemple trois ou quatre essais sur une période de 30 secondes, et à ce que les codes expirent après quelques minutes seulement. L'utilisation de codes alphanumériques peut également renforcer la sécurité en ajoutant des lettres aux chiffres.

Enfin, si possible, évitez d'utiliser des noms d'utilisateur ou des valeurs séquentielles prévisibles comme identifiants de session. Utilisez plutôt un gestionnaire de session côté serveur sécurisé qui génère un identifiant aléatoire à chaque connexion.

La mise en œuvre de méthodes d'authentification sécurisées est un peu plus complexe que la lutte contre les vulnérabilités courantes. Cependant, l'autorisation étant cruciale pour toute application, programme ou API, il est essentiel de prendre le temps nécessaire pour bien faire les choses.

Consultez les pages du blog Secure Code Warrior pour en savoir plus sur cette vulnérabilité et découvrir comment protéger votre organisation et vos clients contre d'autres failles de sécurité. Vous pouvez également demander une démonstration de la plateforme de formation Secure Code Warrior pour maintenir vos compétences en cybersécurité à jour.