Configuration de sécurité incorrecte
La mauvaise configuration de sécurité est un terme générique qui couvre les vulnérabilités courantes découlant des paramètres de configuration d'une application, plutôt que d'un code défectueux. Il s'agit d'un sujet vaste qui dépend fortement de facteurs tels que votre pile technologique.
Il semble souvent simple de résoudre ces problèmes, par exemple en modifiant un fichier de configuration ou une seule ligne de code, mais l'impact et les conséquences de ces vulnérabilités peuvent être graves.
Examinons certaines des catégories ci-dessous.
Catégories
Serveur web
Une mauvaise configuration classique sur les serveurs web est l'activation de l'indexation de répertoire (Directory Listing).
Bien que l'activation de l'indexation de répertoire ait souvent peu ou pas d'impact direct, elle permet à un attaquant de découvrir facilement d'autres erreurs potentielles. Il peut s'agir de pages intentionnellement masquées, de fichiers de sauvegarde ou d'autres éléments similaires.
Il convient de noter que tous ces éléments constituent en soi de mauvaises pratiques et relèvent de la sécurité par l'obscurité.
L'indexation de répertoire est très facile à désactiver et renforce la défense en profondeur en rendant plus coûteux pour un attaquant l'énumération de l'hôte afin d'y trouver des vecteurs d'attaque potentiels.
Frameworks
Mode débogage
La plupart des frameworks proposent un mode « débogage » pour les développeurs. Ce mode, entre autres, affiche généralement les détails de la trace de la pile (stacktrace) lorsqu'une exception non gérée se produit. Certains frameworks affichent même des extraits de code avec la trace de la pile. Cela peut être extrêmement utile lors du développement, mais peut également fournir aux attaquants de nombreuses informations auxquelles ils ne devraient pas avoir accès.
Points de terminaison de surveillance
De nombreux frameworks disposent également d'un ensemble de points de terminaison activables permettant de surveiller l'application, que ce soit dans un environnement de production ou de test/développement.
Ceux-ci peuvent inclure :
- Métriques (Prometheus)
- Journaux
- Informations sur l'environnement
- Mappages de chemins/URL
Bien que ces informations ne soient généralement pas sensibles, elles peuvent tout de même fournir des détails aidant des attaquants potentiels à mieux comprendre votre application. Bien entendu, votre environnement ou vos journaux peuvent effectivement contenir des informations sensibles ; il est donc important de rester vigilant quant à ce qui pourrait être visible et exploité si des regards indiscrets venaient à y accéder.
La distinction entre les environnements de production et hors production
Les gens font souvent l'erreur de ne pas suivre les directives telles que la désactivation de l'indexation de répertoire, du mode débogage et des points de terminaison de débogage dans les environnements de développement/test, et ne le font que dans les environnements de production. La logique est que ces systèmes hors 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 d'explorer et d'extraire des informations de systèmes hors production, puis d'utiliser ces données 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 leurs environnements de test, ce qui accroît encore davantage les risques.
XXE
L'une des erreurs de configuration de sécurité les plus critiques concerne les entités externes XML (XXE).
Cela se produit lorsque vous analysez des sources non fiables avec la résolution d'entités activée, ce qui a longtemps été le cas par défaut. Les attaques XXE peuvent notamment entraîner la lecture arbitraire de fichiers et la falsification de requêtes côté serveur.
Consultez l'exemple ci-dessous pour plus de détails et un cas concret de cette vulnérabilité.
Le codage sécurisé en pratique
Explorez nos directives de développement sécurisé pour comprendre et atténuer les vulnérabilités logicielles telles que l'OWASP Top 10, et plongez dans des missions de formation guidées pour vous exercer sur des simulations d'applications réelles.