Icônes SCW
héros bg sans séparateur
Blog

コーダーがセキュリティを征服する OWASP トップ 10 API シリーズ-認証失敗

Dr Matthias Madu
Publié le 16 septembre 2020
Dernière mise à jour le 10 mars 2026

Il n'est pas étonnant que l'authentification brisée figure sur la liste des problèmes d'API de l'OWASP - les mécanismes d'authentification sont notoirement difficiles à mettre en œuvre correctement. Les mécanismes d'authentification sont notoirement difficiles à mettre en œuvre correctement. De plus, les attaquants ont un petit avantage car, de par leur nature même, la plupart des défis d'authentification doivent être exposés aux utilisateurs, ce qui leur donne 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 tentante pour les attaquants. Si un processus d'authentification est défaillant ou vulnérable, il y a de fortes chances que des attaquants découvrent cette faiblesse et l'exploitent.

Dans ce chapitre, nous allons donc apprendre à faire taire les méchants lorsqu'il s'agit de problèmes d'authentification. Si vous souhaitez d'abord tester vos compétences, rendez-vous sur notre site et jouez à notre défi ludique :

Vous voulez améliorer votre score ? Restez avec moi pour en savoir plus.

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

Un exemple où le problème peut ne pas être aussi évident est celui d'une méthode d'authentification vulnérable au "credential stuffing", c'est-à-dire à l'utilisation de listes de noms d'utilisateur et de mots de passe connus pour enfreindre la sécurité. Même une méthode d'autorisation normalement très sûre, comme l'authentification multifactorielle, peut être vulnérable si les demandes ne sont pas limitées, étranglées ou contrôlé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 message texte SMS où un code à six chiffres est envoyé au 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. Un pirate n'a qu'à envoyer toutes les combinaisons possibles de six chiffres dans l'application jusqu'à ce qu'il trouve la bonne.

Dans ce scénario, il semble que l'authentification à deux facteurs permette d'assurer la sécurité de l'application. Mais comme l'entrée de l'utilisateur n'est pas limitée par le taux, l'authentification est défaillante et vulnérable.

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

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

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

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

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

Élimination des authentifications erronées ou mal configurées

Si l'authentification échoue, il y a de fortes chances que la sécurité de l'ensemble du système soit compromise. Le respect de quelques règles importantes lors du codage des applications peut toutefois contribuer à garantir la sécurité de l'ensemble.

Tout d'abord, veillez à inclure des contrôles d'authentification partout où les utilisateurs peuvent accéder aux fonctionnalités du programme. Si le contrôle d'authentification n'existe pas du tout, la bataille est perdue d'avance.

En termes de bonnes pratiques, une bonne chose à garder à l'esprit est d'éviter d'exposer les identifiants de session dans l'URL accessible aux utilisateurs. Dans le deuxième exemple ci-dessus concernant l'authentification brisée, il est beaucoup plus facile d'empêcher un attaquant d'essayer de décoder le cookie de session s'il n'y est jamais exposé.

C'est également une bonne idée de mettre en place une authentification multifactorielle. Celle-ci peut être réalisée en toute sécurité à l'aide de jetons matériels qui génèrent algorithmiquement des mots de passe selon un calendrier serré. Si vous n'êtes pas en mesure de fournir à vos utilisateurs des dispositifs de ce type, les SMS peuvent également faire l'affaire. Mais vous devez vous assurer que les demandes des utilisateurs sont limitées à quelque chose de raisonnable, comme trois ou quatre tentatives par période de 30 secondes, et que les codes expirent tous au bout de quelques minutes seulement. L'utilisation d'un code alphanumérique peut également améliorer la sécurité en ajoutant des lettres et des chiffres aux mots de passe potentiels.

Enfin, dans la mesure du 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 sécurisé côté serveur qui génère à chaque fois un identifiant de session aléatoire.

La mise en œuvre de méthodes d'authentification sécurisées est un peu plus délicate que la lutte contre la vulnérabilité moyenne. Mais comme l'autorisation est si importante pour chaque application, programme et API, il vaut la peine de prendre le temps de s'assurer que vous y parvenez.

Consultez les pages du Secure Code Warrior pour en savoir plus sur cette vulnérabilité et sur la manière de protéger votre organisation et vos clients des ravages causés par d'autres failles de sécurité. Vous pouvez également essayer une démo de la plateforme de formation Secure Code Warrior pour maintenir vos compétences en cybersécurité à jour.


Afficher les ressources
Afficher les ressources

認証は、多くの場合、アプリケーションへのゲートウェイとしてだけでなく、ネットワークの他の部分へのゲートウェイとしても機能するため、攻撃者にとって魅力的な標的です。認証プロセスが壊れていたり脆弱だったりすると、攻撃者がその弱点を発見して悪用する可能性が高くなります。

Souhaitez-vous en savoir davantage ?

Le Dr Matias Madou est expert en sécurité, chercheur, directeur technique et cofondateur de Secure Code Warrior. Matias a obtenu un doctorat en sécurité des applications, axé sur les solutions d'analyse statique, à l'université de Gand.Il a ensuite rejoint Fortify aux États-Unis, où il a réalisé qu'il ne suffisait pas de détecter les problèmes de code sans aider les développeurs à écrire du code sécurisé. Cela l'a amené à développer des produits qui aident les développeurs, allègent la charge de la sécurité et dépassent les attentes des clients. Lorsqu'il n'est pas à son bureau en tant que membre de Team Awesome, il apprécie de faire des présentations sur scène lors de conférences telles que RSA, BlackHat et DefCon.

En savoir plus

Secure Code Warrior vous assiste dans la protection de votre code tout au long du cycle de vie du développement logiciel et dans la création d'une culture qui accorde la priorité à la cybersécurité. Que vous soyez responsable de la sécurité des applications, développeur, responsable de la sécurité des systèmes d'information ou professionnel de la sécurité, nous vous aidons à réduire les risques liés au code non sécurisé.

Veuillez réserver une démonstration.
Partager :
marques LinkedInSocialLogo x
Auteur
Dr Matthias Madu
Publié le 16 septembre 2020

Le Dr Matias Madou est expert en sécurité, chercheur, directeur technique et cofondateur de Secure Code Warrior. Matias a obtenu un doctorat en sécurité des applications, axé sur les solutions d'analyse statique, à l'université de Gand.Il a ensuite rejoint Fortify aux États-Unis, où il a réalisé qu'il ne suffisait pas de détecter les problèmes de code sans aider les développeurs à écrire du code sécurisé. Cela l'a amené à développer des produits qui aident les développeurs, allègent la charge de la sécurité et dépassent les attentes des clients. Lorsqu'il n'est pas à son bureau en tant que membre de Team Awesome, il apprécie de faire des présentations sur scène lors de conférences telles que RSA, BlackHat et DefCon.

Matias est un chercheur et développeur qui possède plus de 15 ans d'expérience pratique dans le domaine de la sécurité logicielle. Il a développé des solutions pour des entreprises telles que Fortify Software et sa propre société, Sensei Security. Tout au long de sa carrière, Matias a dirigé plusieurs projets de recherche sur la sécurité des applications, qui ont abouti à la création de produits commerciaux et à l'obtention de plus de 10 brevets.Lorsqu'il n'est pas à son bureau, Matias enseigne dans le cadre de formations avancées sur la sécurité des applications et intervient régulièrement lors de conférences internationales telles que RSA Conference, Black Hat, DefCon, BSIMM, OWASP AppSec et BruCon.

Matthias a obtenu un doctorat en génie informatique à l'université de Gand, où il a étudié la sécurité des applications grâce à l'obfuscation des programmes visant à masquer le fonctionnement interne des applications.

Partager :
marques LinkedInSocialLogo x

Il n'est pas étonnant que l'authentification brisée figure sur la liste des problèmes d'API de l'OWASP - les mécanismes d'authentification sont notoirement difficiles à mettre en œuvre correctement. Les mécanismes d'authentification sont notoirement difficiles à mettre en œuvre correctement. De plus, les attaquants ont un petit avantage car, de par leur nature même, la plupart des défis d'authentification doivent être exposés aux utilisateurs, ce qui leur donne 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 tentante pour les attaquants. Si un processus d'authentification est défaillant ou vulnérable, il y a de fortes chances que des attaquants découvrent cette faiblesse et l'exploitent.

Dans ce chapitre, nous allons donc apprendre à faire taire les méchants lorsqu'il s'agit de problèmes d'authentification. Si vous souhaitez d'abord tester vos compétences, rendez-vous sur notre site et jouez à notre défi ludique :

Vous voulez améliorer votre score ? Restez avec moi pour en savoir plus.

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

Un exemple où le problème peut ne pas être aussi évident est celui d'une méthode d'authentification vulnérable au "credential stuffing", c'est-à-dire à l'utilisation de listes de noms d'utilisateur et de mots de passe connus pour enfreindre la sécurité. Même une méthode d'autorisation normalement très sûre, comme l'authentification multifactorielle, peut être vulnérable si les demandes ne sont pas limitées, étranglées ou contrôlé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 message texte SMS où un code à six chiffres est envoyé au 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. Un pirate n'a qu'à envoyer toutes les combinaisons possibles de six chiffres dans l'application jusqu'à ce qu'il trouve la bonne.

Dans ce scénario, il semble que l'authentification à deux facteurs permette d'assurer la sécurité de l'application. Mais comme l'entrée de l'utilisateur n'est pas limitée par le taux, l'authentification est défaillante et vulnérable.

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

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

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

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

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

Élimination des authentifications erronées ou mal configurées

Si l'authentification échoue, il y a de fortes chances que la sécurité de l'ensemble du système soit compromise. Le respect de quelques règles importantes lors du codage des applications peut toutefois contribuer à garantir la sécurité de l'ensemble.

Tout d'abord, veillez à inclure des contrôles d'authentification partout où les utilisateurs peuvent accéder aux fonctionnalités du programme. Si le contrôle d'authentification n'existe pas du tout, la bataille est perdue d'avance.

En termes de bonnes pratiques, une bonne chose à garder à l'esprit est d'éviter d'exposer les identifiants de session dans l'URL accessible aux utilisateurs. Dans le deuxième exemple ci-dessus concernant l'authentification brisée, il est beaucoup plus facile d'empêcher un attaquant d'essayer de décoder le cookie de session s'il n'y est jamais exposé.

C'est également une bonne idée de mettre en place une authentification multifactorielle. Celle-ci peut être réalisée en toute sécurité à l'aide de jetons matériels qui génèrent algorithmiquement des mots de passe selon un calendrier serré. Si vous n'êtes pas en mesure de fournir à vos utilisateurs des dispositifs de ce type, les SMS peuvent également faire l'affaire. Mais vous devez vous assurer que les demandes des utilisateurs sont limitées à quelque chose de raisonnable, comme trois ou quatre tentatives par période de 30 secondes, et que les codes expirent tous au bout de quelques minutes seulement. L'utilisation d'un code alphanumérique peut également améliorer la sécurité en ajoutant des lettres et des chiffres aux mots de passe potentiels.

Enfin, dans la mesure du 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 sécurisé côté serveur qui génère à chaque fois un identifiant de session aléatoire.

La mise en œuvre de méthodes d'authentification sécurisées est un peu plus délicate que la lutte contre la vulnérabilité moyenne. Mais comme l'autorisation est si importante pour chaque application, programme et API, il vaut la peine de prendre le temps de s'assurer que vous y parvenez.

Consultez les pages du Secure Code Warrior pour en savoir plus sur cette vulnérabilité et sur la manière de protéger votre organisation et vos clients des ravages causés par d'autres failles de sécurité. Vous pouvez également essayer une démo de la plateforme de formation Secure Code Warrior pour maintenir vos compétences en cybersécurité à jour.


Afficher les ressources
Afficher les ressources

Pour télécharger le rapport, veuillez remplir le formulaire ci-dessous.

Nous vous prions de bien vouloir nous autoriser à vous envoyer des informations sur nos produits et/ou sur des sujets liés au codage sécurisé. Nous traitons vos informations personnelles avec le plus grand soin et ne les vendons jamais à des tiers à des fins marketing.

Envoi
icône de réussite scw
icône d'erreur scw
Pour envoyer le formulaire, veuillez activer le cookie « Analytics ». Une fois le paramétrage terminé, vous pouvez le désactiver à nouveau.

Il n'est pas étonnant que l'authentification brisée figure sur la liste des problèmes d'API de l'OWASP - les mécanismes d'authentification sont notoirement difficiles à mettre en œuvre correctement. Les mécanismes d'authentification sont notoirement difficiles à mettre en œuvre correctement. De plus, les attaquants ont un petit avantage car, de par leur nature même, la plupart des défis d'authentification doivent être exposés aux utilisateurs, ce qui leur donne 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 tentante pour les attaquants. Si un processus d'authentification est défaillant ou vulnérable, il y a de fortes chances que des attaquants découvrent cette faiblesse et l'exploitent.

Dans ce chapitre, nous allons donc apprendre à faire taire les méchants lorsqu'il s'agit de problèmes d'authentification. Si vous souhaitez d'abord tester vos compétences, rendez-vous sur notre site et jouez à notre défi ludique :

Vous voulez améliorer votre score ? Restez avec moi pour en savoir plus.

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

Un exemple où le problème peut ne pas être aussi évident est celui d'une méthode d'authentification vulnérable au "credential stuffing", c'est-à-dire à l'utilisation de listes de noms d'utilisateur et de mots de passe connus pour enfreindre la sécurité. Même une méthode d'autorisation normalement très sûre, comme l'authentification multifactorielle, peut être vulnérable si les demandes ne sont pas limitées, étranglées ou contrôlé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 message texte SMS où un code à six chiffres est envoyé au 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. Un pirate n'a qu'à envoyer toutes les combinaisons possibles de six chiffres dans l'application jusqu'à ce qu'il trouve la bonne.

Dans ce scénario, il semble que l'authentification à deux facteurs permette d'assurer la sécurité de l'application. Mais comme l'entrée de l'utilisateur n'est pas limitée par le taux, l'authentification est défaillante et vulnérable.

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

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

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

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

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

Élimination des authentifications erronées ou mal configurées

Si l'authentification échoue, il y a de fortes chances que la sécurité de l'ensemble du système soit compromise. Le respect de quelques règles importantes lors du codage des applications peut toutefois contribuer à garantir la sécurité de l'ensemble.

Tout d'abord, veillez à inclure des contrôles d'authentification partout où les utilisateurs peuvent accéder aux fonctionnalités du programme. Si le contrôle d'authentification n'existe pas du tout, la bataille est perdue d'avance.

En termes de bonnes pratiques, une bonne chose à garder à l'esprit est d'éviter d'exposer les identifiants de session dans l'URL accessible aux utilisateurs. Dans le deuxième exemple ci-dessus concernant l'authentification brisée, il est beaucoup plus facile d'empêcher un attaquant d'essayer de décoder le cookie de session s'il n'y est jamais exposé.

C'est également une bonne idée de mettre en place une authentification multifactorielle. Celle-ci peut être réalisée en toute sécurité à l'aide de jetons matériels qui génèrent algorithmiquement des mots de passe selon un calendrier serré. Si vous n'êtes pas en mesure de fournir à vos utilisateurs des dispositifs de ce type, les SMS peuvent également faire l'affaire. Mais vous devez vous assurer que les demandes des utilisateurs sont limitées à quelque chose de raisonnable, comme trois ou quatre tentatives par période de 30 secondes, et que les codes expirent tous au bout de quelques minutes seulement. L'utilisation d'un code alphanumérique peut également améliorer la sécurité en ajoutant des lettres et des chiffres aux mots de passe potentiels.

Enfin, dans la mesure du 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 sécurisé côté serveur qui génère à chaque fois un identifiant de session aléatoire.

La mise en œuvre de méthodes d'authentification sécurisées est un peu plus délicate que la lutte contre la vulnérabilité moyenne. Mais comme l'autorisation est si importante pour chaque application, programme et API, il vaut la peine de prendre le temps de s'assurer que vous y parvenez.

Consultez les pages du Secure Code Warrior pour en savoir plus sur cette vulnérabilité et sur la manière de protéger votre organisation et vos clients des ravages causés par d'autres failles de sécurité. Vous pouvez également essayer une démo de la plateforme de formation Secure Code Warrior pour maintenir vos compétences en cybersécurité à jour.


Veuillez consulter le séminaire en ligne.
Commençons
En savoir plus

Veuillez cliquer sur le lien ci-dessous pour télécharger le PDF de cette ressource.

Secure Code Warrior vous assiste dans la protection de votre code tout au long du cycle de vie du développement logiciel et dans la création d'une culture qui accorde la priorité à la cybersécurité. Que vous soyez responsable de la sécurité des applications, développeur, responsable de la sécurité des systèmes d'information ou professionnel de la sécurité, nous vous aidons à réduire les risques liés au code non sécurisé.

Afficher le rapportVeuillez réserver une démonstration.
Télécharger le PDF
Afficher les ressources
Partager :
marques LinkedInSocialLogo x
Souhaitez-vous en savoir davantage ?

Partager :
marques LinkedInSocialLogo x
Auteur
Dr Matthias Madu
Publié le 16 septembre 2020

Le Dr Matias Madou est expert en sécurité, chercheur, directeur technique et cofondateur de Secure Code Warrior. Matias a obtenu un doctorat en sécurité des applications, axé sur les solutions d'analyse statique, à l'université de Gand.Il a ensuite rejoint Fortify aux États-Unis, où il a réalisé qu'il ne suffisait pas de détecter les problèmes de code sans aider les développeurs à écrire du code sécurisé. Cela l'a amené à développer des produits qui aident les développeurs, allègent la charge de la sécurité et dépassent les attentes des clients. Lorsqu'il n'est pas à son bureau en tant que membre de Team Awesome, il apprécie de faire des présentations sur scène lors de conférences telles que RSA, BlackHat et DefCon.

Matias est un chercheur et développeur qui possède plus de 15 ans d'expérience pratique dans le domaine de la sécurité logicielle. Il a développé des solutions pour des entreprises telles que Fortify Software et sa propre société, Sensei Security. Tout au long de sa carrière, Matias a dirigé plusieurs projets de recherche sur la sécurité des applications, qui ont abouti à la création de produits commerciaux et à l'obtention de plus de 10 brevets.Lorsqu'il n'est pas à son bureau, Matias enseigne dans le cadre de formations avancées sur la sécurité des applications et intervient régulièrement lors de conférences internationales telles que RSA Conference, Black Hat, DefCon, BSIMM, OWASP AppSec et BruCon.

Matthias a obtenu un doctorat en génie informatique à l'université de Gand, où il a étudié la sécurité des applications grâce à l'obfuscation des programmes visant à masquer le fonctionnement interne des applications.

Partager :
marques LinkedInSocialLogo x

Il n'est pas étonnant que l'authentification brisée figure sur la liste des problèmes d'API de l'OWASP - les mécanismes d'authentification sont notoirement difficiles à mettre en œuvre correctement. Les mécanismes d'authentification sont notoirement difficiles à mettre en œuvre correctement. De plus, les attaquants ont un petit avantage car, de par leur nature même, la plupart des défis d'authentification doivent être exposés aux utilisateurs, ce qui leur donne 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 tentante pour les attaquants. Si un processus d'authentification est défaillant ou vulnérable, il y a de fortes chances que des attaquants découvrent cette faiblesse et l'exploitent.

Dans ce chapitre, nous allons donc apprendre à faire taire les méchants lorsqu'il s'agit de problèmes d'authentification. Si vous souhaitez d'abord tester vos compétences, rendez-vous sur notre site et jouez à notre défi ludique :

Vous voulez améliorer votre score ? Restez avec moi pour en savoir plus.

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

Un exemple où le problème peut ne pas être aussi évident est celui d'une méthode d'authentification vulnérable au "credential stuffing", c'est-à-dire à l'utilisation de listes de noms d'utilisateur et de mots de passe connus pour enfreindre la sécurité. Même une méthode d'autorisation normalement très sûre, comme l'authentification multifactorielle, peut être vulnérable si les demandes ne sont pas limitées, étranglées ou contrôlé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 message texte SMS où un code à six chiffres est envoyé au 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. Un pirate n'a qu'à envoyer toutes les combinaisons possibles de six chiffres dans l'application jusqu'à ce qu'il trouve la bonne.

Dans ce scénario, il semble que l'authentification à deux facteurs permette d'assurer la sécurité de l'application. Mais comme l'entrée de l'utilisateur n'est pas limitée par le taux, l'authentification est défaillante et vulnérable.

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

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

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

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

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

Élimination des authentifications erronées ou mal configurées

Si l'authentification échoue, il y a de fortes chances que la sécurité de l'ensemble du système soit compromise. Le respect de quelques règles importantes lors du codage des applications peut toutefois contribuer à garantir la sécurité de l'ensemble.

Tout d'abord, veillez à inclure des contrôles d'authentification partout où les utilisateurs peuvent accéder aux fonctionnalités du programme. Si le contrôle d'authentification n'existe pas du tout, la bataille est perdue d'avance.

En termes de bonnes pratiques, une bonne chose à garder à l'esprit est d'éviter d'exposer les identifiants de session dans l'URL accessible aux utilisateurs. Dans le deuxième exemple ci-dessus concernant l'authentification brisée, il est beaucoup plus facile d'empêcher un attaquant d'essayer de décoder le cookie de session s'il n'y est jamais exposé.

C'est également une bonne idée de mettre en place une authentification multifactorielle. Celle-ci peut être réalisée en toute sécurité à l'aide de jetons matériels qui génèrent algorithmiquement des mots de passe selon un calendrier serré. Si vous n'êtes pas en mesure de fournir à vos utilisateurs des dispositifs de ce type, les SMS peuvent également faire l'affaire. Mais vous devez vous assurer que les demandes des utilisateurs sont limitées à quelque chose de raisonnable, comme trois ou quatre tentatives par période de 30 secondes, et que les codes expirent tous au bout de quelques minutes seulement. L'utilisation d'un code alphanumérique peut également améliorer la sécurité en ajoutant des lettres et des chiffres aux mots de passe potentiels.

Enfin, dans la mesure du 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 sécurisé côté serveur qui génère à chaque fois un identifiant de session aléatoire.

La mise en œuvre de méthodes d'authentification sécurisées est un peu plus délicate que la lutte contre la vulnérabilité moyenne. Mais comme l'autorisation est si importante pour chaque application, programme et API, il vaut la peine de prendre le temps de s'assurer que vous y parvenez.

Consultez les pages du Secure Code Warrior pour en savoir plus sur cette vulnérabilité et sur la manière de protéger votre organisation et vos clients des ravages causés par d'autres failles de sécurité. Vous pouvez également essayer une démo de la plateforme de formation Secure Code Warrior pour maintenir vos compétences en cybersécurité à jour.


Table des matières

Télécharger le PDF
Afficher les ressources
Souhaitez-vous en savoir davantage ?

Le Dr Matias Madou est expert en sécurité, chercheur, directeur technique et cofondateur de Secure Code Warrior. Matias a obtenu un doctorat en sécurité des applications, axé sur les solutions d'analyse statique, à l'université de Gand.Il a ensuite rejoint Fortify aux États-Unis, où il a réalisé qu'il ne suffisait pas de détecter les problèmes de code sans aider les développeurs à écrire du code sécurisé. Cela l'a amené à développer des produits qui aident les développeurs, allègent la charge de la sécurité et dépassent les attentes des clients. Lorsqu'il n'est pas à son bureau en tant que membre de Team Awesome, il apprécie de faire des présentations sur scène lors de conférences telles que RSA, BlackHat et DefCon.

En savoir plus

Secure Code Warrior vous assiste dans la protection de votre code tout au long du cycle de vie du développement logiciel et dans la création d'une culture qui accorde la priorité à la cybersécurité. Que vous soyez responsable de la sécurité des applications, développeur, responsable de la sécurité des systèmes d'information ou professionnel de la sécurité, nous vous aidons à réduire les risques liés au code non sécurisé.

Veuillez réserver une démonstration.[Télécharger]
Partager :
marques LinkedInSocialLogo x
Centre de ressources

Ressources pour débuter

Autres publications
Centre de ressources

Ressources pour débuter

Autres publications