SCW图标
英雄背景无分隔线
博客

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

马蒂亚斯-马杜博士
出版日期: 2020 年 9 月 16 日
最后更新于 2026年3月8日

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.


显示资源
显示资源

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.

您想了解更多吗?

Matias Madou, Ph.D.是一位安全专家、研究员和CTO,也是Secure Code Warrior 的联合创始人。Matias在根特大学获得了应用安全的博士学位,主要研究静态分析解决方案。后来他加入了美国的Fortify公司,在那里他意识到,仅仅检测代码问题而不帮助开发人员编写安全代码是不够的。这激发了他开发产品的热情,帮助开发人员,减轻安全的负担,并超越客户的期望。当他不在办公桌前作为Awesome团队的一员时,他喜欢站在舞台上,在包括RSA会议、BlackHat和DefCon等会议上发表演讲。

了解更多

Secure Code Warrior 在整个软件开发周期中保障代码安全,并营造将网络安全置于首位的企业文化。无论您是应用安全负责人、开发人员、信息安全主管,还是其他任何参与安全工作的人员,我们都能协助您的组织降低不安全代码带来的风险。

预约演示
分享到:
领英品牌社交x 标志
作者
马蒂亚斯-马杜博士
发表于2020年9月16日

Matias Madou, Ph.D.是一位安全专家、研究员和CTO,也是Secure Code Warrior 的联合创始人。Matias在根特大学获得了应用安全的博士学位,主要研究静态分析解决方案。后来他加入了美国的Fortify公司,在那里他意识到,仅仅检测代码问题而不帮助开发人员编写安全代码是不够的。这激发了他开发产品的热情,帮助开发人员,减轻安全的负担,并超越客户的期望。当他不在办公桌前作为Awesome团队的一员时,他喜欢站在舞台上,在包括RSA会议、BlackHat和DefCon等会议上发表演讲。

马蒂亚斯是一名研究员和开发人员,拥有超过15年的软件安全实践经验。他曾为Fortify Software和他自己的公司Sensei Security等公司开发解决方案。在他的职业生涯中,马蒂亚斯领导了多个应用安全研究项目,并将其转化为商业产品,他拥有超过10项专利。当他离开办公桌时,Matias曾担任高级应用安全培训courses ,并定期在全球会议上发言,包括RSA会议、黑帽、DefCon、BSIMM、OWASP AppSec和BruCon。

马蒂亚斯拥有根特大学的计算机工程博士学位,在那里他研究了通过程序混淆来隐藏应用程序的内部工作的应用安全。

分享到:
领英品牌社交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.


显示资源
显示资源

请填写以下表格以下载报告

我们希望获得您的授权,以便向您发送有关我们产品和/或安全编码相关主题的信息。我们将始终以最高标准谨慎处理您的个人数据,绝不会将其出售给其他企业用于营销目的。

提交
scw 成功图标
SCW 错误图标
要提交表单,请启用「Analytics」Cookie。完成操作后,请随时将其重新禁用。

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.


查看网络研讨会
开始
了解更多

点击下方链接,下载此资源的PDF文件。

Secure Code Warrior 在整个软件开发周期中保障代码安全,并营造将网络安全置于首位的企业文化。无论您是应用安全负责人、开发人员、信息安全主管,还是其他任何参与安全工作的人员,我们都能协助您的组织降低不安全代码带来的风险。

显示报告预约演示
下载PDF文件
显示资源
分享到:
领英品牌社交x 标志
您想了解更多吗?

分享到:
领英品牌社交x 标志
作者
马蒂亚斯-马杜博士
发表于2020年9月16日

Matias Madou, Ph.D.是一位安全专家、研究员和CTO,也是Secure Code Warrior 的联合创始人。Matias在根特大学获得了应用安全的博士学位,主要研究静态分析解决方案。后来他加入了美国的Fortify公司,在那里他意识到,仅仅检测代码问题而不帮助开发人员编写安全代码是不够的。这激发了他开发产品的热情,帮助开发人员,减轻安全的负担,并超越客户的期望。当他不在办公桌前作为Awesome团队的一员时,他喜欢站在舞台上,在包括RSA会议、BlackHat和DefCon等会议上发表演讲。

马蒂亚斯是一名研究员和开发人员,拥有超过15年的软件安全实践经验。他曾为Fortify Software和他自己的公司Sensei Security等公司开发解决方案。在他的职业生涯中,马蒂亚斯领导了多个应用安全研究项目,并将其转化为商业产品,他拥有超过10项专利。当他离开办公桌时,Matias曾担任高级应用安全培训courses ,并定期在全球会议上发言,包括RSA会议、黑帽、DefCon、BSIMM、OWASP AppSec和BruCon。

马蒂亚斯拥有根特大学的计算机工程博士学位,在那里他研究了通过程序混淆来隐藏应用程序的内部工作的应用安全。

分享到:
领英品牌社交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.


目录

下载PDF文件
显示资源
您想了解更多吗?

Matias Madou, Ph.D.是一位安全专家、研究员和CTO,也是Secure Code Warrior 的联合创始人。Matias在根特大学获得了应用安全的博士学位,主要研究静态分析解决方案。后来他加入了美国的Fortify公司,在那里他意识到,仅仅检测代码问题而不帮助开发人员编写安全代码是不够的。这激发了他开发产品的热情,帮助开发人员,减轻安全的负担,并超越客户的期望。当他不在办公桌前作为Awesome团队的一员时,他喜欢站在舞台上,在包括RSA会议、BlackHat和DefCon等会议上发表演讲。

了解更多

Secure Code Warrior 在整个软件开发周期中保障代码安全,并营造将网络安全置于首位的企业文化。无论您是应用安全负责人、开发人员、信息安全主管,还是其他任何参与安全工作的人员,我们都能协助您的组织降低不安全代码带来的风险。

预约演示下载
分享到:
领英品牌社交x 标志
资源中心

帮助您入门的资源

更多帖子
资源中心

帮助您入门的资源

更多帖子