Iconos SCW
héroe bg sin separador
Blog

Les 10 meilleures séries d'API de Coders Conquer Security OWASP : fonctionnalités de sécurité désactivées/fonctionnalités de débogage activées/autorisations inappropriées

Doctor Matias Madou
Publicado el 11 de noviembre de 2020
Última actualización el 8 de marzo de 2026

Bien que la plupart des vulnérabilités de cette liste soient assez spécifiques aux API, le problème des fonctionnalités de sécurité désactivées/des fonctionnalités de débogage activées/des autorisations inappropriées peut survenir n'importe où. Elle est probablement un peu plus répandue dans les API, mais les attaquants tentent souvent de détecter des failles non corrigées et des fichiers ou répertoires non protégés n'importe où sur un réseau. Le fait de tomber sur une API dont le débogage est activé ou dont les fonctionnalités de sécurité sont désactivées facilite un peu leur travail néfaste. Pire encore, des outils automatisés sont disponibles pour détecter et exploiter les erreurs de sécurité. Si vous en avez dans votre environnement, il y a de fortes chances qu'elles soient exploitées. C'est pourquoi cette vulnérabilité figure sur la liste OWASP des failles d'API dangereuses.

Avant de nous amuser, voyez si vous pouvez résoudre ce défi de débogage :

Comment les fonctionnalités de sécurité désactivées/les fonctionnalités de débogage activées/la faille d'autorisations inappropriées se faufilent-elles dans une API ?

Pour voir comment cette faille d'API multidimensionnelle s'ajoute aux réseaux, nous devons la décomposer en ses composants. Commençons par le problème des fonctionnalités de débogage activées. Le débogage est un outil utile qui aide les développeurs à comprendre pourquoi les applications ne fonctionnent pas correctement ou génèrent des erreurs. Lorsque le débogage est activé, les erreurs et les exceptions génèrent des pages d'erreur détaillées permettant aux développeurs de voir ce qui ne va pas et de résoudre les problèmes. C'est parfaitement normal de l'activer pendant qu'une application est encore en développement.

Cependant, il y a une raison pour laquelle la plupart des frameworks sont accompagnés d'avertissements concernant l'exécution du mode de débogage dans un environnement de production, probablement directement dans le code où le débogage est activé. Par exemple :

# AVERTISSEMENT DE SÉCURITÉ : ne lancez pas avec le débogage activé en production !
DEBUG = Vrai

Dans cet exemple, le débogage a été activé. L'application Django génère des pages d'erreur détaillées lorsqu'une exception est déclenchée. Si cela est fait dans un environnement de production, un adversaire aura accès à ces pages d'erreur, qui incluent des informations de métadonnées relatives à l'environnement. Bien que le débogage soit désactivé par défaut dans la plupart des frameworks, il est facile d'oublier de le désactiver s'il est activé au cours d'un long processus de développement. Ensuite, lorsque l'application passe à un environnement de production, elle fournit aux attaquants de nombreuses informations sur la manière de compromettre une application, voire l'ensemble d'un serveur ou d'un réseau.

Bien que l'activation du mode de débogage soit principalement un problème autonome, les autorisations inappropriées et les vulnérabilités des fonctionnalités de sécurité désactivées fonctionnent souvent de pair. Par exemple, dans un scénario réel fourni par l'OWASP, un attaquant a utilisé un moteur de recherche pour trouver une base de données connectée accidentellement à Internet. Le célèbre système de gestion de base de données utilisant sa configuration par défaut, l'authentification a été désactivée. Ainsi, en combinant les autorisations inappropriées et les vulnérabilités des fonctionnalités de sécurité désactivées, l'attaquant a eu accès à des millions d'enregistrements contenant des informations personnelles, des préférences personnelles et des données d'authentification.

Élimination des vulnérabilités liées aux fonctionnalités de sécurité désactivées/aux fonctionnalités de débogage activées/aux autorisations inappropriées

Vous devrez probablement adopter une approche en deux volets pour éliminer cette vulnérabilité. Pour supprimer la partie activée du problème liée au débogage, ajoutez simplement une vérification au processus de développement pour vous assurer que le débogage est désactivé avant de déplacer une API ou une application vers l'environnement de production. D'après notre exemple, la commande appropriée pour ce faire serait la suivante :

# AVERTISSEMENT DE SÉCURITÉ : ne lancez pas avec le débogage activé en production !
DEBUG = Faux

Les fonctionnalités de débogage de l'application Django sont désormais désactivées avec l'indicateur DEBUG configuré sur False. Aucune page d'erreur ne sera générée en réponse à des erreurs. Si un adversaire parvient toujours à accéder aux pages d'erreur, celles-ci ne contiendront aucune métadonnée utile et ne présenteront aucun risque pour l'application.

Il est un peu plus difficile d'éliminer les fonctionnalités de sécurité désactivées et les vulnérabilités liées aux autorisations inappropriées, car elles peuvent englober un large éventail de vulnérabilités spécifiques. Le meilleur moyen de les arrêter est de développer un processus standard et reproductible permettant le déploiement rapide et facile des actifs verrouillés dans l'environnement de production.

Même dans ce cas, vous devez créer un processus dans lequel les fichiers d'orchestration, les composants d'API et les services cloud tels que les autorisations des compartiments Amazon S3 sont constamment revus et mis à jour. Cet examen devrait également évaluer l'efficacité globale des paramètres de sécurité dans l'ensemble de l'environnement au fil du temps afin de s'assurer que l'organisation améliore constamment la sécurité de ses API.

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.


Mostrar el recurso
Mostrar el recurso

Elle est probablement un peu plus répandue dans les API, mais les attaquants tentent souvent de détecter des failles non corrigées et des fichiers ou répertoires non protégés n'importe où sur un réseau. Le fait de tomber sur une API dont le débogage est activé ou dont les fonctionnalités de sécurité sont désactivées facilite un peu leur travail néfaste.

¿Desea obtener más información?

Matias Madou, Ph.D. es experto en seguridad, investigador y CTO y cofundador de Secure Code Warrior. Matias obtuvo su doctorado en Seguridad de Aplicaciones en la Universidad de Gante, centrándose en soluciones de análisis estático. Más tarde se incorporó a Fortify en EE.UU., donde se dio cuenta de que no bastaba con detectar problemas de código sin ayudar a los desarrolladores a escribir código seguro. Esto le inspiró para desarrollar productos que ayuden a los desarrolladores, alivien la carga de la seguridad y superen las expectativas de los clientes. Cuando no está en su escritorio como parte de Team Awesome, le gusta estar en el escenario presentando en conferencias como RSA Conference, BlackHat y DefCon.

Más información

Secure Code Warrior aquí para ayudar a su organización a proteger el código a lo largo de todo el ciclo de desarrollo de software y a crear una cultura en la que la ciberseguridad sea una prioridad. Tanto si es responsable de la seguridad de las aplicaciones, desarrollador, responsable de la seguridad informática o cualquier otra persona involucrada en la seguridad, podemos ayudar a su organización a reducir los riesgos asociados a un código no seguro.

Reserve una demostración
Compartir en:
marcas de LinkedInSocialx logotipo
Autor
Doctor Matias Madou
Publicado el 11 de noviembre de 2020

Matias Madou, Ph.D. es experto en seguridad, investigador y CTO y cofundador de Secure Code Warrior. Matias obtuvo su doctorado en Seguridad de Aplicaciones en la Universidad de Gante, centrándose en soluciones de análisis estático. Más tarde se incorporó a Fortify en EE.UU., donde se dio cuenta de que no bastaba con detectar problemas de código sin ayudar a los desarrolladores a escribir código seguro. Esto le inspiró para desarrollar productos que ayuden a los desarrolladores, alivien la carga de la seguridad y superen las expectativas de los clientes. Cuando no está en su escritorio como parte de Team Awesome, le gusta estar en el escenario presentando en conferencias como RSA Conference, BlackHat y DefCon.

Matías es un investigador y desarrollador con más de 15 años de experiencia práctica en seguridad de software. Ha desarrollado soluciones para empresas como Fortify Software y su propia empresa Sensei Security. A lo largo de su carrera, Matías ha dirigido múltiples proyectos de investigación sobre seguridad de aplicaciones que han dado lugar a productos comerciales y cuenta con más de 10 patentes en su haber. Cuando está lejos de su escritorio, Matias ha servido como instructor para la formación de seguridad de aplicaciones avanzadas courses y regularmente habla en conferencias mundiales como la Conferencia RSA, Black Hat, DefCon, BSIMM, OWASP AppSec y BruCon.

Matías es doctor en Ingeniería Informática por la Universidad de Gante, donde estudió la seguridad de las aplicaciones mediante la ofuscación de programas para ocultar el funcionamiento interno de una aplicación.

Compartir en:
marcas de LinkedInSocialx logotipo

Bien que la plupart des vulnérabilités de cette liste soient assez spécifiques aux API, le problème des fonctionnalités de sécurité désactivées/des fonctionnalités de débogage activées/des autorisations inappropriées peut survenir n'importe où. Elle est probablement un peu plus répandue dans les API, mais les attaquants tentent souvent de détecter des failles non corrigées et des fichiers ou répertoires non protégés n'importe où sur un réseau. Le fait de tomber sur une API dont le débogage est activé ou dont les fonctionnalités de sécurité sont désactivées facilite un peu leur travail néfaste. Pire encore, des outils automatisés sont disponibles pour détecter et exploiter les erreurs de sécurité. Si vous en avez dans votre environnement, il y a de fortes chances qu'elles soient exploitées. C'est pourquoi cette vulnérabilité figure sur la liste OWASP des failles d'API dangereuses.

Avant de nous amuser, voyez si vous pouvez résoudre ce défi de débogage :

Comment les fonctionnalités de sécurité désactivées/les fonctionnalités de débogage activées/la faille d'autorisations inappropriées se faufilent-elles dans une API ?

Pour voir comment cette faille d'API multidimensionnelle s'ajoute aux réseaux, nous devons la décomposer en ses composants. Commençons par le problème des fonctionnalités de débogage activées. Le débogage est un outil utile qui aide les développeurs à comprendre pourquoi les applications ne fonctionnent pas correctement ou génèrent des erreurs. Lorsque le débogage est activé, les erreurs et les exceptions génèrent des pages d'erreur détaillées permettant aux développeurs de voir ce qui ne va pas et de résoudre les problèmes. C'est parfaitement normal de l'activer pendant qu'une application est encore en développement.

Cependant, il y a une raison pour laquelle la plupart des frameworks sont accompagnés d'avertissements concernant l'exécution du mode de débogage dans un environnement de production, probablement directement dans le code où le débogage est activé. Par exemple :

# AVERTISSEMENT DE SÉCURITÉ : ne lancez pas avec le débogage activé en production !
DEBUG = Vrai

Dans cet exemple, le débogage a été activé. L'application Django génère des pages d'erreur détaillées lorsqu'une exception est déclenchée. Si cela est fait dans un environnement de production, un adversaire aura accès à ces pages d'erreur, qui incluent des informations de métadonnées relatives à l'environnement. Bien que le débogage soit désactivé par défaut dans la plupart des frameworks, il est facile d'oublier de le désactiver s'il est activé au cours d'un long processus de développement. Ensuite, lorsque l'application passe à un environnement de production, elle fournit aux attaquants de nombreuses informations sur la manière de compromettre une application, voire l'ensemble d'un serveur ou d'un réseau.

Bien que l'activation du mode de débogage soit principalement un problème autonome, les autorisations inappropriées et les vulnérabilités des fonctionnalités de sécurité désactivées fonctionnent souvent de pair. Par exemple, dans un scénario réel fourni par l'OWASP, un attaquant a utilisé un moteur de recherche pour trouver une base de données connectée accidentellement à Internet. Le célèbre système de gestion de base de données utilisant sa configuration par défaut, l'authentification a été désactivée. Ainsi, en combinant les autorisations inappropriées et les vulnérabilités des fonctionnalités de sécurité désactivées, l'attaquant a eu accès à des millions d'enregistrements contenant des informations personnelles, des préférences personnelles et des données d'authentification.

Élimination des vulnérabilités liées aux fonctionnalités de sécurité désactivées/aux fonctionnalités de débogage activées/aux autorisations inappropriées

Vous devrez probablement adopter une approche en deux volets pour éliminer cette vulnérabilité. Pour supprimer la partie activée du problème liée au débogage, ajoutez simplement une vérification au processus de développement pour vous assurer que le débogage est désactivé avant de déplacer une API ou une application vers l'environnement de production. D'après notre exemple, la commande appropriée pour ce faire serait la suivante :

# AVERTISSEMENT DE SÉCURITÉ : ne lancez pas avec le débogage activé en production !
DEBUG = Faux

Les fonctionnalités de débogage de l'application Django sont désormais désactivées avec l'indicateur DEBUG configuré sur False. Aucune page d'erreur ne sera générée en réponse à des erreurs. Si un adversaire parvient toujours à accéder aux pages d'erreur, celles-ci ne contiendront aucune métadonnée utile et ne présenteront aucun risque pour l'application.

Il est un peu plus difficile d'éliminer les fonctionnalités de sécurité désactivées et les vulnérabilités liées aux autorisations inappropriées, car elles peuvent englober un large éventail de vulnérabilités spécifiques. Le meilleur moyen de les arrêter est de développer un processus standard et reproductible permettant le déploiement rapide et facile des actifs verrouillés dans l'environnement de production.

Même dans ce cas, vous devez créer un processus dans lequel les fichiers d'orchestration, les composants d'API et les services cloud tels que les autorisations des compartiments Amazon S3 sont constamment revus et mis à jour. Cet examen devrait également évaluer l'efficacité globale des paramètres de sécurité dans l'ensemble de l'environnement au fil du temps afin de s'assurer que l'organisation améliore constamment la sécurité de ses API.

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.


Mostrar el recurso
Mostrar el recurso

Rellene el siguiente formulario para descargar el informe.

Nos gustaría obtener su autorización para enviarle información sobre nuestros productos y/o sobre temas relacionados con la codificación segura. Siempre trataremos sus datos personales con el mayor cuidado y nunca los venderemos a otras empresas con fines de marketing.

Enviar
Icono de éxito de SCW
Icono de error scw
Para enviar el formulario, active las cookies «Analytics». No dude en desactivarlas de nuevo una vez que haya terminado.

Bien que la plupart des vulnérabilités de cette liste soient assez spécifiques aux API, le problème des fonctionnalités de sécurité désactivées/des fonctionnalités de débogage activées/des autorisations inappropriées peut survenir n'importe où. Elle est probablement un peu plus répandue dans les API, mais les attaquants tentent souvent de détecter des failles non corrigées et des fichiers ou répertoires non protégés n'importe où sur un réseau. Le fait de tomber sur une API dont le débogage est activé ou dont les fonctionnalités de sécurité sont désactivées facilite un peu leur travail néfaste. Pire encore, des outils automatisés sont disponibles pour détecter et exploiter les erreurs de sécurité. Si vous en avez dans votre environnement, il y a de fortes chances qu'elles soient exploitées. C'est pourquoi cette vulnérabilité figure sur la liste OWASP des failles d'API dangereuses.

Avant de nous amuser, voyez si vous pouvez résoudre ce défi de débogage :

Comment les fonctionnalités de sécurité désactivées/les fonctionnalités de débogage activées/la faille d'autorisations inappropriées se faufilent-elles dans une API ?

Pour voir comment cette faille d'API multidimensionnelle s'ajoute aux réseaux, nous devons la décomposer en ses composants. Commençons par le problème des fonctionnalités de débogage activées. Le débogage est un outil utile qui aide les développeurs à comprendre pourquoi les applications ne fonctionnent pas correctement ou génèrent des erreurs. Lorsque le débogage est activé, les erreurs et les exceptions génèrent des pages d'erreur détaillées permettant aux développeurs de voir ce qui ne va pas et de résoudre les problèmes. C'est parfaitement normal de l'activer pendant qu'une application est encore en développement.

Cependant, il y a une raison pour laquelle la plupart des frameworks sont accompagnés d'avertissements concernant l'exécution du mode de débogage dans un environnement de production, probablement directement dans le code où le débogage est activé. Par exemple :

# AVERTISSEMENT DE SÉCURITÉ : ne lancez pas avec le débogage activé en production !
DEBUG = Vrai

Dans cet exemple, le débogage a été activé. L'application Django génère des pages d'erreur détaillées lorsqu'une exception est déclenchée. Si cela est fait dans un environnement de production, un adversaire aura accès à ces pages d'erreur, qui incluent des informations de métadonnées relatives à l'environnement. Bien que le débogage soit désactivé par défaut dans la plupart des frameworks, il est facile d'oublier de le désactiver s'il est activé au cours d'un long processus de développement. Ensuite, lorsque l'application passe à un environnement de production, elle fournit aux attaquants de nombreuses informations sur la manière de compromettre une application, voire l'ensemble d'un serveur ou d'un réseau.

Bien que l'activation du mode de débogage soit principalement un problème autonome, les autorisations inappropriées et les vulnérabilités des fonctionnalités de sécurité désactivées fonctionnent souvent de pair. Par exemple, dans un scénario réel fourni par l'OWASP, un attaquant a utilisé un moteur de recherche pour trouver une base de données connectée accidentellement à Internet. Le célèbre système de gestion de base de données utilisant sa configuration par défaut, l'authentification a été désactivée. Ainsi, en combinant les autorisations inappropriées et les vulnérabilités des fonctionnalités de sécurité désactivées, l'attaquant a eu accès à des millions d'enregistrements contenant des informations personnelles, des préférences personnelles et des données d'authentification.

Élimination des vulnérabilités liées aux fonctionnalités de sécurité désactivées/aux fonctionnalités de débogage activées/aux autorisations inappropriées

Vous devrez probablement adopter une approche en deux volets pour éliminer cette vulnérabilité. Pour supprimer la partie activée du problème liée au débogage, ajoutez simplement une vérification au processus de développement pour vous assurer que le débogage est désactivé avant de déplacer une API ou une application vers l'environnement de production. D'après notre exemple, la commande appropriée pour ce faire serait la suivante :

# AVERTISSEMENT DE SÉCURITÉ : ne lancez pas avec le débogage activé en production !
DEBUG = Faux

Les fonctionnalités de débogage de l'application Django sont désormais désactivées avec l'indicateur DEBUG configuré sur False. Aucune page d'erreur ne sera générée en réponse à des erreurs. Si un adversaire parvient toujours à accéder aux pages d'erreur, celles-ci ne contiendront aucune métadonnée utile et ne présenteront aucun risque pour l'application.

Il est un peu plus difficile d'éliminer les fonctionnalités de sécurité désactivées et les vulnérabilités liées aux autorisations inappropriées, car elles peuvent englober un large éventail de vulnérabilités spécifiques. Le meilleur moyen de les arrêter est de développer un processus standard et reproductible permettant le déploiement rapide et facile des actifs verrouillés dans l'environnement de production.

Même dans ce cas, vous devez créer un processus dans lequel les fichiers d'orchestration, les composants d'API et les services cloud tels que les autorisations des compartiments Amazon S3 sont constamment revus et mis à jour. Cet examen devrait également évaluer l'efficacité globale des paramètres de sécurité dans l'ensemble de l'environnement au fil du temps afin de s'assurer que l'organisation améliore constamment la sécurité de ses API.

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.


Ver el seminario web
Comience
Más información

Haga clic en el enlace siguiente y descargue el PDF de este recurso.

Secure Code Warrior aquí para ayudar a su organización a proteger el código a lo largo de todo el ciclo de desarrollo de software y a crear una cultura en la que la ciberseguridad sea una prioridad. Tanto si es responsable de la seguridad de las aplicaciones, desarrollador, responsable de la seguridad informática o cualquier otra persona involucrada en la seguridad, podemos ayudar a su organización a reducir los riesgos asociados a un código no seguro.

Mostrar el informeReserve una demostración
Descargar el PDF
Mostrar el recurso
Compartir en:
marcas de LinkedInSocialx logotipo
¿Desea obtener más información?

Compartir en:
marcas de LinkedInSocialx logotipo
Autor
Doctor Matias Madou
Publicado el 11 de noviembre de 2020

Matias Madou, Ph.D. es experto en seguridad, investigador y CTO y cofundador de Secure Code Warrior. Matias obtuvo su doctorado en Seguridad de Aplicaciones en la Universidad de Gante, centrándose en soluciones de análisis estático. Más tarde se incorporó a Fortify en EE.UU., donde se dio cuenta de que no bastaba con detectar problemas de código sin ayudar a los desarrolladores a escribir código seguro. Esto le inspiró para desarrollar productos que ayuden a los desarrolladores, alivien la carga de la seguridad y superen las expectativas de los clientes. Cuando no está en su escritorio como parte de Team Awesome, le gusta estar en el escenario presentando en conferencias como RSA Conference, BlackHat y DefCon.

Matías es un investigador y desarrollador con más de 15 años de experiencia práctica en seguridad de software. Ha desarrollado soluciones para empresas como Fortify Software y su propia empresa Sensei Security. A lo largo de su carrera, Matías ha dirigido múltiples proyectos de investigación sobre seguridad de aplicaciones que han dado lugar a productos comerciales y cuenta con más de 10 patentes en su haber. Cuando está lejos de su escritorio, Matias ha servido como instructor para la formación de seguridad de aplicaciones avanzadas courses y regularmente habla en conferencias mundiales como la Conferencia RSA, Black Hat, DefCon, BSIMM, OWASP AppSec y BruCon.

Matías es doctor en Ingeniería Informática por la Universidad de Gante, donde estudió la seguridad de las aplicaciones mediante la ofuscación de programas para ocultar el funcionamiento interno de una aplicación.

Compartir en:
marcas de LinkedInSocialx logotipo

Bien que la plupart des vulnérabilités de cette liste soient assez spécifiques aux API, le problème des fonctionnalités de sécurité désactivées/des fonctionnalités de débogage activées/des autorisations inappropriées peut survenir n'importe où. Elle est probablement un peu plus répandue dans les API, mais les attaquants tentent souvent de détecter des failles non corrigées et des fichiers ou répertoires non protégés n'importe où sur un réseau. Le fait de tomber sur une API dont le débogage est activé ou dont les fonctionnalités de sécurité sont désactivées facilite un peu leur travail néfaste. Pire encore, des outils automatisés sont disponibles pour détecter et exploiter les erreurs de sécurité. Si vous en avez dans votre environnement, il y a de fortes chances qu'elles soient exploitées. C'est pourquoi cette vulnérabilité figure sur la liste OWASP des failles d'API dangereuses.

Avant de nous amuser, voyez si vous pouvez résoudre ce défi de débogage :

Comment les fonctionnalités de sécurité désactivées/les fonctionnalités de débogage activées/la faille d'autorisations inappropriées se faufilent-elles dans une API ?

Pour voir comment cette faille d'API multidimensionnelle s'ajoute aux réseaux, nous devons la décomposer en ses composants. Commençons par le problème des fonctionnalités de débogage activées. Le débogage est un outil utile qui aide les développeurs à comprendre pourquoi les applications ne fonctionnent pas correctement ou génèrent des erreurs. Lorsque le débogage est activé, les erreurs et les exceptions génèrent des pages d'erreur détaillées permettant aux développeurs de voir ce qui ne va pas et de résoudre les problèmes. C'est parfaitement normal de l'activer pendant qu'une application est encore en développement.

Cependant, il y a une raison pour laquelle la plupart des frameworks sont accompagnés d'avertissements concernant l'exécution du mode de débogage dans un environnement de production, probablement directement dans le code où le débogage est activé. Par exemple :

# AVERTISSEMENT DE SÉCURITÉ : ne lancez pas avec le débogage activé en production !
DEBUG = Vrai

Dans cet exemple, le débogage a été activé. L'application Django génère des pages d'erreur détaillées lorsqu'une exception est déclenchée. Si cela est fait dans un environnement de production, un adversaire aura accès à ces pages d'erreur, qui incluent des informations de métadonnées relatives à l'environnement. Bien que le débogage soit désactivé par défaut dans la plupart des frameworks, il est facile d'oublier de le désactiver s'il est activé au cours d'un long processus de développement. Ensuite, lorsque l'application passe à un environnement de production, elle fournit aux attaquants de nombreuses informations sur la manière de compromettre une application, voire l'ensemble d'un serveur ou d'un réseau.

Bien que l'activation du mode de débogage soit principalement un problème autonome, les autorisations inappropriées et les vulnérabilités des fonctionnalités de sécurité désactivées fonctionnent souvent de pair. Par exemple, dans un scénario réel fourni par l'OWASP, un attaquant a utilisé un moteur de recherche pour trouver une base de données connectée accidentellement à Internet. Le célèbre système de gestion de base de données utilisant sa configuration par défaut, l'authentification a été désactivée. Ainsi, en combinant les autorisations inappropriées et les vulnérabilités des fonctionnalités de sécurité désactivées, l'attaquant a eu accès à des millions d'enregistrements contenant des informations personnelles, des préférences personnelles et des données d'authentification.

Élimination des vulnérabilités liées aux fonctionnalités de sécurité désactivées/aux fonctionnalités de débogage activées/aux autorisations inappropriées

Vous devrez probablement adopter une approche en deux volets pour éliminer cette vulnérabilité. Pour supprimer la partie activée du problème liée au débogage, ajoutez simplement une vérification au processus de développement pour vous assurer que le débogage est désactivé avant de déplacer une API ou une application vers l'environnement de production. D'après notre exemple, la commande appropriée pour ce faire serait la suivante :

# AVERTISSEMENT DE SÉCURITÉ : ne lancez pas avec le débogage activé en production !
DEBUG = Faux

Les fonctionnalités de débogage de l'application Django sont désormais désactivées avec l'indicateur DEBUG configuré sur False. Aucune page d'erreur ne sera générée en réponse à des erreurs. Si un adversaire parvient toujours à accéder aux pages d'erreur, celles-ci ne contiendront aucune métadonnée utile et ne présenteront aucun risque pour l'application.

Il est un peu plus difficile d'éliminer les fonctionnalités de sécurité désactivées et les vulnérabilités liées aux autorisations inappropriées, car elles peuvent englober un large éventail de vulnérabilités spécifiques. Le meilleur moyen de les arrêter est de développer un processus standard et reproductible permettant le déploiement rapide et facile des actifs verrouillés dans l'environnement de production.

Même dans ce cas, vous devez créer un processus dans lequel les fichiers d'orchestration, les composants d'API et les services cloud tels que les autorisations des compartiments Amazon S3 sont constamment revus et mis à jour. Cet examen devrait également évaluer l'efficacité globale des paramètres de sécurité dans l'ensemble de l'environnement au fil du temps afin de s'assurer que l'organisation améliore constamment la sécurité de ses API.

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.


Índice

Descargar el PDF
Mostrar el recurso
¿Desea obtener más información?

Matias Madou, Ph.D. es experto en seguridad, investigador y CTO y cofundador de Secure Code Warrior. Matias obtuvo su doctorado en Seguridad de Aplicaciones en la Universidad de Gante, centrándose en soluciones de análisis estático. Más tarde se incorporó a Fortify en EE.UU., donde se dio cuenta de que no bastaba con detectar problemas de código sin ayudar a los desarrolladores a escribir código seguro. Esto le inspiró para desarrollar productos que ayuden a los desarrolladores, alivien la carga de la seguridad y superen las expectativas de los clientes. Cuando no está en su escritorio como parte de Team Awesome, le gusta estar en el escenario presentando en conferencias como RSA Conference, BlackHat y DefCon.

Más información

Secure Code Warrior aquí para ayudar a su organización a proteger el código a lo largo de todo el ciclo de desarrollo de software y a crear una cultura en la que la ciberseguridad sea una prioridad. Tanto si es responsable de la seguridad de las aplicaciones, desarrollador, responsable de la seguridad informática o cualquier otra persona involucrada en la seguridad, podemos ayudar a su organización a reducir los riesgos asociados a un código no seguro.

Reserve una demostraciónDescargar
Compartir en:
marcas de LinkedInSocialx logotipo
Centro de recursos

Recursos para ayudarle a empezar

Más publicaciones
Centro de recursos

Recursos para ayudarle a empezar

Más publicaciones