Mauvaise configuration de la sécurité
La mauvaise configuration de la sécurité est en quelque sorte un terme générique qui couvre les vulnérabilités courantes qui entrent en jeu à cause des paramètres de configuration d'une application, plutôt qu'à cause d'un mauvais code. Il s'agit d'un sujet très vaste qui dépend fortement de facteurs tels que votre pile technologique.
Souvent, la résolution de ces problèmes semble simple, comme la modification d'un fichier de configuration ou même d'une seule ligne de code, mais l'impact et les conséquences de ces vulnérabilités peuvent être graves.
Examinons quelques-unes des catégories ci-dessous.
Catégories
Serveur web
Une erreur de configuration classique sur les serveurs web est l'activation du Directory Listing.
Bien que l'activation du Directory Listing n'ait souvent que peu ou pas d'impact direct, elle permet à un pirate de découvrir facilement d'autres erreurs qui pourraient exister. Il peut s'agir de pages intentionnellement cachées, de fichiers de sauvegarde ou d'autres éléments similaires.
Il convient de noter que tous ces éléments sont en soi de mauvaises pratiques et qu'ils relèvent de la sécurité par l'obscurité.
Le Directory Listing est trivial à désactiver et ajoute une défense en profondeur en rendant plus coûteux pour un attaquant d'énumérer l'hôte pour trouver des vecteurs d'attaque potentiels contre lui.
Cadres de travail
Mode débogage
La plupart des frameworks proposent un mode "débogage" aux développeurs. Ce mode, entre autres, affiche généralement les détails de l'historique lorsqu'une exception non gérée se produit. Certains frameworks affichent même des extraits de code à côté de la trace de la pile. Cela peut s'avérer extrêmement utile lors du développement, mais peut également fournir aux attaquants de nombreuses informations auxquelles ils ne devraient pas avoir accès.
Suivi des résultats
De nombreux frameworks disposent également d'un ensemble de points d'extrémité qui peuvent être activés pour permettre le contrôle de l'application, que ce soit dans un environnement de production ou de test/dev.
Il peut s'agir de
- Métriques (Prometheus)
- Journaux
- Informations sur l'environnement
- Correspondance chemin/Url
Bien que ces informations ne soient généralement pas sensibles, elles peuvent néanmoins fournir des détails qui aident les attaquants potentiels à mieux comprendre votre application. Bien entendu , votre environnement ou vos journaux peuvent contenir des informations sensibles, il est donc important de faire attention à ce qui pourrait être visible et utilisé si des yeux indiscrets tombaient dessus.
La distinction entre les environnements de production et de non-production
Les gens commettent souvent l'erreur de ne pas suivre les directives telles que la désactivation de la liste des répertoires, du mode de débogage et des points de terminaison de débogage dans les environnements de développement et de test, et de ne le faire que dans les environnements de production. La raison en est que ces systèmes de non-production sont destinés aux tests et qu'il est important d'obtenir les informations fournies par ces fonctionnalités.
Cette mentalité est toutefois erronée. Les attaquants sont toujours en mesure de sonder et de divulguer des informations à partir de systèmes qui ne sont pas des systèmes de production, puis d'utiliser les informations recueillies dans le système de test pour attaquer votre système de production. Il n'est pas rare non plus de trouver des entreprises qui utilisent des copies de leur base de données de production dans des systèmes de test, ce qui augmente encore le risque.
XXE
Les entités externes XML (XXE) constituent un type de mauvaise configuration de la sécurité très grave.
Cela se produit lorsque vous analysez à partir de sources non fiables avec la résolution d'entité activée, ce qui a toujours été le cas. XXE peut conduire à la lecture arbitraire de fichiers et à la falsification de requêtes côté serveur, entre autres choses.
Consultez l'exemple ci-dessous pour plus de détails et un exemple simple de ce cas particulier.