
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
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.


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.
Matias Madou, Ph.D. セキュリティ専門家、研究者、CTO兼共同設立者(Secure Code Warrior )。Ghent大学でアプリケーションセキュリティの博士号を取得し、静的解析ソリューションに焦点を当てた。その後、米国Fortify社に入社し、開発者が安全なコードを書くことを支援せずに、コードの問題を検出するだけでは不十分であることに気づきました。開発者を支援し、セキュリティの負担を軽減し、お客様の期待を上回る製品を開発することを志すようになった。Team Awesomeの一員としてデスクワークをしていないときは、RSA Conference、BlackHat、DefConなどのカンファレンスでプレゼンテーションをするのが好きである。

Secure Code Warrior ソフトウェア開発ライフサイクル全体を通じてコードのセキュリティを確保し、サイバーセキュリティを最優先事項とする文化を構築するために、組織をSecure Code Warrior 。アプリケーションセキュリティ担当者、開発者、情報セキュリティ責任者、その他セキュリティに関わるあらゆる方々のために、当社は組織が非セキュアなコードに関連するリスクを軽減するお手伝いをいたします。
デモを予約するMatias Madou, Ph.D. セキュリティ専門家、研究者、CTO兼共同設立者(Secure Code Warrior )。Ghent大学でアプリケーションセキュリティの博士号を取得し、静的解析ソリューションに焦点を当てた。その後、米国Fortify社に入社し、開発者が安全なコードを書くことを支援せずに、コードの問題を検出するだけでは不十分であることに気づきました。開発者を支援し、セキュリティの負担を軽減し、お客様の期待を上回る製品を開発することを志すようになった。Team Awesomeの一員としてデスクワークをしていないときは、RSA Conference、BlackHat、DefConなどのカンファレンスでプレゼンテーションをするのが好きである。
マティアスは、15年以上のソフトウェアセキュリティの実務経験を持つ研究者・開発者です。フォーティファイ・ソフトウェア社や自身の会社(Sensei Security)などでソリューションを開発してきました。キャリアの中で、Matiasは、商用製品につながる複数のアプリケーションセキュリティ研究プロジェクトを主導し、10件以上の特許を取得しています。また、RSAカンファレンス、Black Hat、DefCon、BSIMM、OWASP AppSec、BruConなどの世界的なカンファレンスで定期的に講演を行っているほか、高度なアプリケーションセキュリティトレーニング(courses )の講師も務めています。
Matiasはゲント大学でコンピュータ工学の博士号を取得し、アプリケーションの内部構造を隠すためのプログラム難読化によるアプリケーションセキュリティを研究しました。


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.

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.

以下のリンクをクリックして、このリソースのPDFをダウンロードしてください。
Secure Code Warrior ソフトウェア開発ライフサイクル全体を通じてコードのセキュリティを確保し、サイバーセキュリティを最優先事項とする文化を構築するために、組織をSecure Code Warrior 。アプリケーションセキュリティ担当者、開発者、情報セキュリティ責任者、その他セキュリティに関わるあらゆる方々のために、当社は組織が非セキュアなコードに関連するリスクを軽減するお手伝いをいたします。
レポートを表示するデモを予約するMatias Madou, Ph.D. セキュリティ専門家、研究者、CTO兼共同設立者(Secure Code Warrior )。Ghent大学でアプリケーションセキュリティの博士号を取得し、静的解析ソリューションに焦点を当てた。その後、米国Fortify社に入社し、開発者が安全なコードを書くことを支援せずに、コードの問題を検出するだけでは不十分であることに気づきました。開発者を支援し、セキュリティの負担を軽減し、お客様の期待を上回る製品を開発することを志すようになった。Team Awesomeの一員としてデスクワークをしていないときは、RSA Conference、BlackHat、DefConなどのカンファレンスでプレゼンテーションをするのが好きである。
マティアスは、15年以上のソフトウェアセキュリティの実務経験を持つ研究者・開発者です。フォーティファイ・ソフトウェア社や自身の会社(Sensei Security)などでソリューションを開発してきました。キャリアの中で、Matiasは、商用製品につながる複数のアプリケーションセキュリティ研究プロジェクトを主導し、10件以上の特許を取得しています。また、RSAカンファレンス、Black Hat、DefCon、BSIMM、OWASP AppSec、BruConなどの世界的なカンファレンスで定期的に講演を行っているほか、高度なアプリケーションセキュリティトレーニング(courses )の講師も務めています。
Matiasはゲント大学でコンピュータ工学の博士号を取得し、アプリケーションの内部構造を隠すためのプログラム難読化によるアプリケーションセキュリティを研究しました。
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.
目次
Matias Madou, Ph.D. セキュリティ専門家、研究者、CTO兼共同設立者(Secure Code Warrior )。Ghent大学でアプリケーションセキュリティの博士号を取得し、静的解析ソリューションに焦点を当てた。その後、米国Fortify社に入社し、開発者が安全なコードを書くことを支援せずに、コードの問題を検出するだけでは不十分であることに気づきました。開発者を支援し、セキュリティの負担を軽減し、お客様の期待を上回る製品を開発することを志すようになった。Team Awesomeの一員としてデスクワークをしていないときは、RSA Conference、BlackHat、DefConなどのカンファレンスでプレゼンテーションをするのが好きである。

Secure Code Warrior ソフトウェア開発ライフサイクル全体を通じてコードのセキュリティを確保し、サイバーセキュリティを最優先事項とする文化を構築するために、組織をSecure Code Warrior 。アプリケーションセキュリティ担当者、開発者、情報セキュリティ責任者、その他セキュリティに関わるあらゆる方々のために、当社は組織が非セキュアなコードに関連するリスクを軽減するお手伝いをいたします。
デモを予約するダウンロード



%20(1).avif)
.avif)
