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

Les codeurs conquièrent la série des 10 meilleures API de l'OWASP en matière de sécurité : Authentification non fonctionnelle

Matias Madou, Ph.D.
Publié le 16 septembre 2020
Dernière mise à jour le 8 mars 2026

Il n'est pas étonnant que l'authentification cassée figure sur la liste OWASP pour les problèmes d'API. Les mécanismes d'authentification sont notoirement difficiles à mettre en œuvre correctement. Les attaquants ont également un petit avantage car, de par leur nature même, la plupart des problèmes 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 agit souvent comme une passerelle vers une application et potentiellement vers le reste du 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 les attaquants découvrent cette faille et l'exploitent.

Dans ce chapitre, nous allons donc apprendre comment exclure les méchants en matière de problèmes d'authentification. Si vous voulez d'abord tester vos compétences, lancez-vous et jouez à notre défi gamifié :

Vous souhaitez améliorer votre score ? Restez avec moi pendant que nous le décomposons.

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

Par exemple, le problème n'est peut-être pas aussi évident lorsqu'une méthode d'authentification est vulnérable au bourrage d'informations d'identification ou lorsqu'elle utilise des 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, telle que l'authentification multifactorielle, peut être vulnérable si les demandes ne sont pas limitées, limitées 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/système/codes de vérification et en fournissant un nom d'utilisateur dans le corps de la demande. Si une application utilise un défi par 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 attaquant doit simplement envoyer toutes les combinaisons de six chiffres possibles dans l'application jusqu'à ce qu'il trouve la bonne.

Dans ce scénario, à première vue, il semble que l'authentification à deux facteurs garantira la sécurité d'une application. Mais comme le débit de saisie de l'utilisateur n'est pas limité, 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 pourrait découvrir comment le cookie définit les sessions et les utilisateurs de l'application. Par exemple, ils peuvent voir le JSON suivant une fois décodé :

{
« nom d'utilisateur » : « ShadyGuy »,
« role » : « utilisateur »
{

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

{
« nom d'utilisateur » : « GoodGuy »,
« rôle » : « administrateur »
{

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

Élimination de l'authentification défaillante ou mal configurée

Si l'authentification échoue, il y a de fortes chances que la sécurité soit compromise à tous les niveaux. Cependant, le fait de suivre quelques directives importantes lors du codage des applications peut vous aider à tout sécuriser.

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

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 défaillante, il est beaucoup plus facile d'empêcher un attaquant d'essayer de décoder le cookie de session s'il ne lui est jamais exposé.

C'est également une bonne idée d'implémenter l'authentification multifactorielle. Cela peut être fait en toute sécurité à l'aide de jetons matériels qui génèrent des mots de passe de manière algorithmique dans des délais serrés. Si vous n'êtes pas en mesure de fournir à vos utilisateurs de tels appareils, les SMS peuvent également fonctionner. Mais vous devez vous assurer que les demandes des utilisateurs sont limitées à quelque chose de raisonnable, comme trois ou quatre essais sur une période de 30 secondes, et que les codes expirent tous ensemble 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, si possible, évitez de vous baser sur 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 un identifiant de session aléatoire à chaque fois.

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 plus de temps pour vous assurer de bien faire les choses.

Consultez le Secure Code Warrior pages de blog 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 essayez une démo de la plateforme de formation Secure Code Warrior pour maintenir toutes vos compétences en cybersécurité à jour et à jour.


Afficher la ressource
Afficher la ressource

L'authentification agit souvent comme une passerelle vers une application et potentiellement vers le reste du réseau, ce qui en fait des cibles tentantes 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.

Souhaitez-vous obtenir davantage d'informations ?

Matias Madou est expert en sécurité, chercheur, directeur technique et cofondateur de Secure Code Warrior. Matias a obtenu son doctorat en sécurité des applications à l'université de Gand, en se concentrant sur les solutions d'analyse statique. Il a ensuite rejoint Fortify aux États-Unis, où il s'est rendu compte qu'il ne suffisait pas de détecter les problèmes de code sans aider les développeurs à écrire du code sécurisé. C'est ce qui l'a incité à développer des produits qui aident les développeurs, allègent le fardeau de la sécurité et dépassent les attentes des clients. Lorsqu'il n'est pas à son bureau en tant que membre de l'équipe Awesome, il aime être sur scène pour présenter des conférences, notamment RSA Conference, BlackHat et DefCon.

En savoir plus

Secure Code Warrior là pour aider votre organisation à sécuriser le code tout au long du cycle de développement logiciel et à créer une culture dans laquelle la cybersécurité est une priorité. Que vous soyez responsable de la sécurité des applications, développeur, responsable de la sécurité informatique ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre organisation à réduire les risques associés à un code non sécurisé.

Veuillez réserver une démonstration.
Partager sur :
marques LinkedInSocialLogo x
Auteur
Matias Madou, Ph.D.
Publié le 16 septembre 2020

Matias Madou est expert en sécurité, chercheur, directeur technique et cofondateur de Secure Code Warrior. Matias a obtenu son doctorat en sécurité des applications à l'université de Gand, en se concentrant sur les solutions d'analyse statique. Il a ensuite rejoint Fortify aux États-Unis, où il s'est rendu compte qu'il ne suffisait pas de détecter les problèmes de code sans aider les développeurs à écrire du code sécurisé. C'est ce qui l'a incité à développer des produits qui aident les développeurs, allègent le fardeau de la sécurité et dépassent les attentes des clients. Lorsqu'il n'est pas à son bureau en tant que membre de l'équipe Awesome, il aime être sur scène pour présenter des conférences, notamment RSA Conference, BlackHat et DefCon.

Matias est un chercheur et un développeur qui possède plus de 15 ans d'expérience pratique dans le domaine de la sécurité des logiciels. Il a développé des solutions pour des entreprises telles que Fortify Software et sa propre entreprise Sensei Security. Au cours de sa carrière, Matias a dirigé de nombreux projets de recherche sur la sécurité des applications qui ont débouché sur des produits commerciaux et peut se targuer d'avoir déposé plus de 10 brevets. Lorsqu'il n'est pas à son bureau, Matias a été instructeur pour des formations avancées en matière de sécurité des applications ( courses ) et intervient régulièrement lors de conférences mondiales telles que RSA Conference, Black Hat, DefCon, BSIMM, OWASP AppSec et BruCon.

Matias est titulaire d'un doctorat en ingénierie informatique de l'Université de Gand, où il a étudié la sécurité des applications par le biais de l'obscurcissement des programmes afin de dissimuler le fonctionnement interne d'une application.

Partager sur :
marques LinkedInSocialLogo x

Il n'est pas étonnant que l'authentification cassée figure sur la liste OWASP pour les problèmes d'API. Les mécanismes d'authentification sont notoirement difficiles à mettre en œuvre correctement. Les attaquants ont également un petit avantage car, de par leur nature même, la plupart des problèmes 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 agit souvent comme une passerelle vers une application et potentiellement vers le reste du 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 les attaquants découvrent cette faille et l'exploitent.

Dans ce chapitre, nous allons donc apprendre comment exclure les méchants en matière de problèmes d'authentification. Si vous voulez d'abord tester vos compétences, lancez-vous et jouez à notre défi gamifié :

Vous souhaitez améliorer votre score ? Restez avec moi pendant que nous le décomposons.

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

Par exemple, le problème n'est peut-être pas aussi évident lorsqu'une méthode d'authentification est vulnérable au bourrage d'informations d'identification ou lorsqu'elle utilise des 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, telle que l'authentification multifactorielle, peut être vulnérable si les demandes ne sont pas limitées, limitées 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/système/codes de vérification et en fournissant un nom d'utilisateur dans le corps de la demande. Si une application utilise un défi par 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 attaquant doit simplement envoyer toutes les combinaisons de six chiffres possibles dans l'application jusqu'à ce qu'il trouve la bonne.

Dans ce scénario, à première vue, il semble que l'authentification à deux facteurs garantira la sécurité d'une application. Mais comme le débit de saisie de l'utilisateur n'est pas limité, 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 pourrait découvrir comment le cookie définit les sessions et les utilisateurs de l'application. Par exemple, ils peuvent voir le JSON suivant une fois décodé :

{
« nom d'utilisateur » : « ShadyGuy »,
« role » : « utilisateur »
{

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

{
« nom d'utilisateur » : « GoodGuy »,
« rôle » : « administrateur »
{

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

Élimination de l'authentification défaillante ou mal configurée

Si l'authentification échoue, il y a de fortes chances que la sécurité soit compromise à tous les niveaux. Cependant, le fait de suivre quelques directives importantes lors du codage des applications peut vous aider à tout sécuriser.

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

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 défaillante, il est beaucoup plus facile d'empêcher un attaquant d'essayer de décoder le cookie de session s'il ne lui est jamais exposé.

C'est également une bonne idée d'implémenter l'authentification multifactorielle. Cela peut être fait en toute sécurité à l'aide de jetons matériels qui génèrent des mots de passe de manière algorithmique dans des délais serrés. Si vous n'êtes pas en mesure de fournir à vos utilisateurs de tels appareils, les SMS peuvent également fonctionner. Mais vous devez vous assurer que les demandes des utilisateurs sont limitées à quelque chose de raisonnable, comme trois ou quatre essais sur une période de 30 secondes, et que les codes expirent tous ensemble 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, si possible, évitez de vous baser sur 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 un identifiant de session aléatoire à chaque fois.

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 plus de temps pour vous assurer de bien faire les choses.

Consultez le Secure Code Warrior pages de blog 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 essayez une démo de la plateforme de formation Secure Code Warrior pour maintenir toutes vos compétences en cybersécurité à jour et à jour.


Afficher la ressource
Afficher la ressource

Veuillez remplir le formulaire ci-dessous pour télécharger le rapport.

Nous souhaiterions obtenir votre autorisation pour vous envoyer des informations sur nos produits et/ou sur des sujets liés au codage sécurisé. Nous traiterons toujours vos données personnelles avec le plus grand soin et ne les transmettrons jamais à d'autres entreprises à des fins de marketing.

Soumettre
icône de réussite scw
icône d'erreur scw
Pour soumettre le formulaire, veuillez activer les cookies « Analytics ». N'hésitez pas à les désactiver à nouveau une fois que vous aurez terminé.

Il n'est pas étonnant que l'authentification cassée figure sur la liste OWASP pour les problèmes d'API. Les mécanismes d'authentification sont notoirement difficiles à mettre en œuvre correctement. Les attaquants ont également un petit avantage car, de par leur nature même, la plupart des problèmes 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 agit souvent comme une passerelle vers une application et potentiellement vers le reste du 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 les attaquants découvrent cette faille et l'exploitent.

Dans ce chapitre, nous allons donc apprendre comment exclure les méchants en matière de problèmes d'authentification. Si vous voulez d'abord tester vos compétences, lancez-vous et jouez à notre défi gamifié :

Vous souhaitez améliorer votre score ? Restez avec moi pendant que nous le décomposons.

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

Par exemple, le problème n'est peut-être pas aussi évident lorsqu'une méthode d'authentification est vulnérable au bourrage d'informations d'identification ou lorsqu'elle utilise des 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, telle que l'authentification multifactorielle, peut être vulnérable si les demandes ne sont pas limitées, limitées 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/système/codes de vérification et en fournissant un nom d'utilisateur dans le corps de la demande. Si une application utilise un défi par 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 attaquant doit simplement envoyer toutes les combinaisons de six chiffres possibles dans l'application jusqu'à ce qu'il trouve la bonne.

Dans ce scénario, à première vue, il semble que l'authentification à deux facteurs garantira la sécurité d'une application. Mais comme le débit de saisie de l'utilisateur n'est pas limité, 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 pourrait découvrir comment le cookie définit les sessions et les utilisateurs de l'application. Par exemple, ils peuvent voir le JSON suivant une fois décodé :

{
« nom d'utilisateur » : « ShadyGuy »,
« role » : « utilisateur »
{

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

{
« nom d'utilisateur » : « GoodGuy »,
« rôle » : « administrateur »
{

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

Élimination de l'authentification défaillante ou mal configurée

Si l'authentification échoue, il y a de fortes chances que la sécurité soit compromise à tous les niveaux. Cependant, le fait de suivre quelques directives importantes lors du codage des applications peut vous aider à tout sécuriser.

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

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 défaillante, il est beaucoup plus facile d'empêcher un attaquant d'essayer de décoder le cookie de session s'il ne lui est jamais exposé.

C'est également une bonne idée d'implémenter l'authentification multifactorielle. Cela peut être fait en toute sécurité à l'aide de jetons matériels qui génèrent des mots de passe de manière algorithmique dans des délais serrés. Si vous n'êtes pas en mesure de fournir à vos utilisateurs de tels appareils, les SMS peuvent également fonctionner. Mais vous devez vous assurer que les demandes des utilisateurs sont limitées à quelque chose de raisonnable, comme trois ou quatre essais sur une période de 30 secondes, et que les codes expirent tous ensemble 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, si possible, évitez de vous baser sur 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 un identifiant de session aléatoire à chaque fois.

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 plus de temps pour vous assurer de bien faire les choses.

Consultez le Secure Code Warrior pages de blog 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 essayez une démo de la plateforme de formation Secure Code Warrior pour maintenir toutes vos compétences en cybersécurité à jour et à jour.


Afficher le webinaire
Veuillez commencer
En savoir plus

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

Secure Code Warrior là pour aider votre organisation à sécuriser le code tout au long du cycle de développement logiciel et à créer une culture dans laquelle la cybersécurité est une priorité. Que vous soyez responsable de la sécurité des applications, développeur, responsable de la sécurité informatique ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre organisation à réduire les risques associés à un code non sécurisé.

Veuillez consulter le rapportVeuillez réserver une démonstration.
Télécharger le PDF
Afficher la ressource
Partager sur :
marques LinkedInSocialLogo x
Souhaitez-vous obtenir davantage d'informations ?

Partager sur :
marques LinkedInSocialLogo x
Auteur
Matias Madou, Ph.D.
Publié le 16 septembre 2020

Matias Madou est expert en sécurité, chercheur, directeur technique et cofondateur de Secure Code Warrior. Matias a obtenu son doctorat en sécurité des applications à l'université de Gand, en se concentrant sur les solutions d'analyse statique. Il a ensuite rejoint Fortify aux États-Unis, où il s'est rendu compte qu'il ne suffisait pas de détecter les problèmes de code sans aider les développeurs à écrire du code sécurisé. C'est ce qui l'a incité à développer des produits qui aident les développeurs, allègent le fardeau de la sécurité et dépassent les attentes des clients. Lorsqu'il n'est pas à son bureau en tant que membre de l'équipe Awesome, il aime être sur scène pour présenter des conférences, notamment RSA Conference, BlackHat et DefCon.

Matias est un chercheur et un développeur qui possède plus de 15 ans d'expérience pratique dans le domaine de la sécurité des logiciels. Il a développé des solutions pour des entreprises telles que Fortify Software et sa propre entreprise Sensei Security. Au cours de sa carrière, Matias a dirigé de nombreux projets de recherche sur la sécurité des applications qui ont débouché sur des produits commerciaux et peut se targuer d'avoir déposé plus de 10 brevets. Lorsqu'il n'est pas à son bureau, Matias a été instructeur pour des formations avancées en matière de sécurité des applications ( courses ) et intervient régulièrement lors de conférences mondiales telles que RSA Conference, Black Hat, DefCon, BSIMM, OWASP AppSec et BruCon.

Matias est titulaire d'un doctorat en ingénierie informatique de l'Université de Gand, où il a étudié la sécurité des applications par le biais de l'obscurcissement des programmes afin de dissimuler le fonctionnement interne d'une application.

Partager sur :
marques LinkedInSocialLogo x

Il n'est pas étonnant que l'authentification cassée figure sur la liste OWASP pour les problèmes d'API. Les mécanismes d'authentification sont notoirement difficiles à mettre en œuvre correctement. Les attaquants ont également un petit avantage car, de par leur nature même, la plupart des problèmes 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 agit souvent comme une passerelle vers une application et potentiellement vers le reste du 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 les attaquants découvrent cette faille et l'exploitent.

Dans ce chapitre, nous allons donc apprendre comment exclure les méchants en matière de problèmes d'authentification. Si vous voulez d'abord tester vos compétences, lancez-vous et jouez à notre défi gamifié :

Vous souhaitez améliorer votre score ? Restez avec moi pendant que nous le décomposons.

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

Par exemple, le problème n'est peut-être pas aussi évident lorsqu'une méthode d'authentification est vulnérable au bourrage d'informations d'identification ou lorsqu'elle utilise des 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, telle que l'authentification multifactorielle, peut être vulnérable si les demandes ne sont pas limitées, limitées 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/système/codes de vérification et en fournissant un nom d'utilisateur dans le corps de la demande. Si une application utilise un défi par 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 attaquant doit simplement envoyer toutes les combinaisons de six chiffres possibles dans l'application jusqu'à ce qu'il trouve la bonne.

Dans ce scénario, à première vue, il semble que l'authentification à deux facteurs garantira la sécurité d'une application. Mais comme le débit de saisie de l'utilisateur n'est pas limité, 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 pourrait découvrir comment le cookie définit les sessions et les utilisateurs de l'application. Par exemple, ils peuvent voir le JSON suivant une fois décodé :

{
« nom d'utilisateur » : « ShadyGuy »,
« role » : « utilisateur »
{

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

{
« nom d'utilisateur » : « GoodGuy »,
« rôle » : « administrateur »
{

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

Élimination de l'authentification défaillante ou mal configurée

Si l'authentification échoue, il y a de fortes chances que la sécurité soit compromise à tous les niveaux. Cependant, le fait de suivre quelques directives importantes lors du codage des applications peut vous aider à tout sécuriser.

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

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 défaillante, il est beaucoup plus facile d'empêcher un attaquant d'essayer de décoder le cookie de session s'il ne lui est jamais exposé.

C'est également une bonne idée d'implémenter l'authentification multifactorielle. Cela peut être fait en toute sécurité à l'aide de jetons matériels qui génèrent des mots de passe de manière algorithmique dans des délais serrés. Si vous n'êtes pas en mesure de fournir à vos utilisateurs de tels appareils, les SMS peuvent également fonctionner. Mais vous devez vous assurer que les demandes des utilisateurs sont limitées à quelque chose de raisonnable, comme trois ou quatre essais sur une période de 30 secondes, et que les codes expirent tous ensemble 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, si possible, évitez de vous baser sur 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 un identifiant de session aléatoire à chaque fois.

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 plus de temps pour vous assurer de bien faire les choses.

Consultez le Secure Code Warrior pages de blog 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 essayez une démo de la plateforme de formation Secure Code Warrior pour maintenir toutes vos compétences en cybersécurité à jour et à jour.


Table des matières

Télécharger le PDF
Afficher la ressource
Souhaitez-vous obtenir davantage d'informations ?

Matias Madou est expert en sécurité, chercheur, directeur technique et cofondateur de Secure Code Warrior. Matias a obtenu son doctorat en sécurité des applications à l'université de Gand, en se concentrant sur les solutions d'analyse statique. Il a ensuite rejoint Fortify aux États-Unis, où il s'est rendu compte qu'il ne suffisait pas de détecter les problèmes de code sans aider les développeurs à écrire du code sécurisé. C'est ce qui l'a incité à développer des produits qui aident les développeurs, allègent le fardeau de la sécurité et dépassent les attentes des clients. Lorsqu'il n'est pas à son bureau en tant que membre de l'équipe Awesome, il aime être sur scène pour présenter des conférences, notamment RSA Conference, BlackHat et DefCon.

En savoir plus

Secure Code Warrior là pour aider votre organisation à sécuriser le code tout au long du cycle de développement logiciel et à créer une culture dans laquelle la cybersécurité est une priorité. Que vous soyez responsable de la sécurité des applications, développeur, responsable de la sécurité informatique ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre organisation à réduire les risques associés à un code non sécurisé.

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

Ressources pour vous aider à démarrer

Plus de publications
Centre de ressources

Ressources pour vous aider à démarrer

Plus de publications