Série OWASP Top 10 API : Fonctionnalités de sécurité désactivées / Débogage activé / 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, du mode débogage activé et des autorisations inappropriées peut survenir n'importe où. C'est sans doute un peu plus courant dans les API, mais les attaquants tentent souvent de trouver des failles non corrigées et des fichiers ou répertoires non protégés partout sur un réseau. Tomber sur une API avec le débogage activé ou des fonctions de sécurité désactivées facilite grandement leur tâche malveillante. Pire encore, des outils automatisés permettent de détecter et d'exploiter ces erreurs de configuration ; si elles existent dans votre environnement, il est fort probable qu'elles soient exploitées, ce qui explique pourquoi cette vulnérabilité figure dans la liste OWASP des failles API dangereuses.

Avant de passer aux choses sérieuses, essayez de résoudre ce défi de débogage :

Comment la faille liée aux fonctionnalités de sécurité désactivées, au mode débogage activé et aux autorisations inappropriées s'immisce-t-elle dans une API ?

Pour comprendre comment cette faille API multidimensionnelle s'introduit dans les réseaux, nous devons la décomposer. Commençons par le problème du mode débogage activé. 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 exceptions produisent des pages détaillées permettant aux développeurs d'identifier et de corriger les problèmes. Il est tout à fait normal de laisser cette option active pendant la phase de développement.

Cependant, il existe une raison pour laquelle la plupart des frameworks affichent des avertissements concernant l'utilisation du mode débogage en environnement de production, souvent directement dans le code où il est activé. Par exemple :

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

Dans cet exemple, le débogage a été activé. L'application Django générera des pages d'erreur détaillées lorsqu'une exception sera levée. Si cela se produit en environnement de production, un adversaire aura accès à ces pages d'erreur, qui contiennent des métadonnées sur l'environnement. Bien que la plupart des frameworks désactivent le débogage par défaut, il est facile d'oublier de le désactiver après un long processus de développement. Lorsque l'application passe en production, elle fournit alors aux attaquants de nombreuses informations sur la manière de compromettre l'application, voire le serveur ou le réseau tout entier.

Si l'activation du mode débogage est un problème isolé, les vulnérabilités liées aux autorisations inappropriées et aux fonctionnalités de sécurité désactivées vont 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 accidentellement connectée à Internet. Comme le système de gestion de base de données populaire utilisait sa configuration par défaut, l'authentification était désactivée. Ainsi, en combinant les vulnérabilités d'autorisations inappropriées et de fonctionnalités de sécurité désactivées, l'attaquant a accédé à des millions d'enregistrements contenant des données personnelles (PII), des préférences et des données d'authentification.

Éliminer les vulnérabilités liées aux fonctionnalités de sécurité désactivées, au mode débogage activé et aux autorisations inappropriées

Vous devez probablement adopter une approche à deux volets pour éliminer cette vulnérabilité. Pour résoudre le problème du débogage, ajoutez simplement une vérification dans votre processus de développement afin de garantir que le débogage est désactivé avant de déployer une API ou une application en production. D'après notre exemple, la commande appropriée serait la suivante :

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

Désormais, les fonctionnalités de débogage de l'application Django sont désactivées grâce au paramètre DEBUG défini sur False. Aucune page d'erreur ne sera générée en cas de problème. Si un adversaire parvient à accéder aux pages d'erreur, celles-ci ne contiendront aucune métadonnée utile et ne présenteront aucun risque pour l'application.

Éliminer les vulnérabilités liées aux fonctionnalités de sécurité désactivées et aux autorisations inappropriées est plus complexe, car elles peuvent couvrir un large éventail de failles spécifiques. La meilleure façon de les contrer est de développer un processus standard et reproductible permettant un déploiement rapide et sécurisé des ressources en production.

Même dans ce cas, vous devez mettre en place un processus où les fichiers d'orchestration, les composants API et les services cloud, comme les autorisations des compartiments Amazon S3, sont constamment révisés et mis à jour. Cette revue doit également évaluer l'efficacité globale des paramètres de sécurité dans tout l'environnement afin de garantir une amélioration continue de la sécurité des API au sein de l'organisation.

Consultez les pages du blog Secure Code Warrior pour en savoir plus sur cette vulnérabilité et découvrir comment protéger votre organisation et vos clients contre d'autres failles de sécurité. Vous pouvez également demander une démonstration de la plateforme de formation Secure Code Warrior pour maintenir vos compétences en cybersécurité à jour.