Est-ce vraiment une erreur de configuration de la sécurité d'afficher un numéro de version?
Notre application Web utilise un fichier HTML avec jQuery intégré à l'intérieur. Selon la licence jQuery ( https://jquery.org/license/ ), nous devons laisser l'intitulé de la licence intact, y compris le numéro de version.
Notre client a signalé l'exposition de la combinaison de produits et de versions comme un risque pour la sécurité. Étrangement, la version bootstrap dans le même fichier n'est pas signalée comme un risque de sécurité.
De nombreuses applications utilisent des bibliothèques avec des numéros de version à l'intérieur. Il est même possible d'obtenir des numéros de version en exécutant du code dans Firebug ou la console développeur de Chrome.
Dans quelles circonstances cette "mauvaise configuration de la sécurité" ( https://www.owasp.org/index.php/Top_10-2017_A6-Security_Misconfiguration ) s'applique-t-elle à l'affichage du numéro de produit et de version? Et comment pouvons-nous résoudre ce problème sans violer la licence jQuery?
L'impact sur la sécurité de l'exposition du numéro de version est qu'un attaquant peut instantanément voir si votre version est vulnérable à une vulnérabilité connue. Par exemple, jQuery avant 3.4.0 est vulnérable à CVE-2019-11358, il est donc utile pour un attaquant de savoir si votre jQuery est 3.3.9 ou 3.4.1.
Cependant, avec JavaScript qui s'exécute dans le navigateur, le code source complet est accessible par l'attaquant, il est donc impossible de cacher si votre jQuery est vulnérable. Même si vous cachez la version, l'attaquant peut comparer le code, ou simplement essayer un exploit, pour déterminer si vous êtes vulnérable. Masquer le numéro de version peut le rendre légèrement plus efficace, mais en réalité, cela ne fait pas grand-chose.
En outre, il existe d'autres moyens d'atténuer ce problème:
- Restez informé des problèmes de sécurité dans les bibliothèques que vous utilisez. Abonnez-vous à une liste de diffusion ou à une autre méthode de publication pour les problèmes de sécurité.
- Mettez à jour les bibliothèques clientes lorsqu'un problème de sécurité est identifié.
Si vous avez toujours une version non vulnérable parce que vous mettez à jour régulièrement, ce n'est pas un problème que la version soit divulguée. Et vous pouvez dire à votre client que c'est ainsi que vous atténuez la divulgation d'informations.
Connaître le numéro de version n'est pas une erreur de configuration de la sécurité. Le risque d'exposer des numéros de version est une "divulgation d'informations". Cela peut créer un danger si la connaissance de ces informations permet à un attaquant de créer un exploit pour une vulnérabilité dans cette version spécifique.
Même si la bibliothèque finit par contenir une vulnérabilité, il ne s'agit toujours pas d'un problème de mauvaise configuration de la sécurité. Ce serait "A9-Utilisation de composants avec des vulnérabilités connues".
Il apparaît donc que le client a une compréhension incorrecte et rigide des risques et de la situation.
C'est un très, très ancien schéma de pensée en matière de cybersécurité qu'exposer le numéro de version de quelque chose est un danger pour la sécurité.
Apparemment, cela facilite le travail des attaquants, car s'ils connaissent la version de ce que vous utilisez, ils peuvent rechercher les vulnérabilités qui s'appliquent à cette version.
En fait, c'est ce que font les scanners de sécurité. Nessus et al ont une base de données intégrée de vulnérabilités par numéro de version. Donc, à moins que vous ne vous numérisiez jamais, cacher ces informations, c'est vous tirer une balle dans le pied.
Sauf que les scanners et les attaquants (qui utilisent des scanners, vous savez?) Ont d'autres moyens qu'un simple strcmp () pour déterminer le numéro de version de quelque chose. C'est un peu plus d'effort et ne peut pas toujours déterminer un nombre exact, mais aucun attaquant qui vaille quoi que ce soit ne confondra jQuery 3.3.0 avec jQuery 2.2.1
Les attaquants de niveau non script-kiddie ont également plusieurs autres méthodes pour comprendre ce que vous exécutez, de la prise d'empreintes digitales au simple test automatique de quelques centaines d'exploits et à la vérification de ce qui fonctionne.
Masquer le numéro de version vous donne une très petite sécurité supplémentaire. Si vous n'avez plus rien à faire, vous pouvez le faire ou non. Tant que vous avez de vrais problèmes de sécurité à résoudre, passez-y votre temps.
Enfin, exposer le numéro de version n'est pas un cas de configuration incorrecte de la sécurité. Si votre outil le signale comme tel, signalez ce bogue en amont afin que votre outil puisse être corrigé.
Au final, le cacher, c'est la sécurité par l'obscurité.
Ce qui est souvent dénoncé comme un comportement erroné et inutile.
Ce qu'il est, s'il est utilisé SUR SON PROPRE ET CONTRE UNE ATTAQUE CIBLÉE.
Il peut améliorer les mesures de sécurité "appropriées" en réduisant les chances que vous ne soyez pas ciblé en premier lieu par quiconque recherche toujours une cible.
Il minimise le RISQUE.
Une sécurité "correcte", c'est comme s'assurer que vos actions sont légales, la sécurité par l'obscurité, c'est comme vous assurer de ne pas attirer l'attention gratuite de la police au cas où vous vous trompez sur la loi.
Je ne suis pas sûr à 100% s'il s'agit ou non d'une question en double. S'il doit être marqué comme tel, veuillez le faire mods, mais je pense que les conseils dans cet article particulier " Existe-t-il une version de base de jQuery qui n'a pas de vulnérabilité XSS " serait utile pour résoudre le problème pour vos clients.
L'un des principaux facteurs que vous devrez évaluer pour répondre à la question générale est de savoir si la solution de sécurité proposée est un bon retour sur investissement pour votre client. Vaut-il la peine d'écrire une exception dans la politique de sécurité, ou peut-être d'implémenter du code pour supprimer les numéros de version retournés (ou comme le commentateur le note potentiellement en abandonnant jQuery) pour atténuer le risque d'exposer le numéro de version? Dans de nombreux cas, ce ne sera pas le cas, mais dans d'autres, ce sera le cas, et tout dépendra de la situation individuelle. Cependant, vous devez absolument vérifier que les versions que vous utilisez ne sont pas déjà compromises en utilisant quelque chose comme cvedetails ou NIST National Vulnerability Database .
Quant à savoir pourquoi Bootstrap n'est pas signalé, cela est probablement dû au scanner (que vous n'avez pas mentionné) et aux tests que vous utilisez pour l'évaluation. Selon la logique du OWASP Security Misconfiguration elle peut être considérée comme une vulnérabilité également et ne doit/ne doit pas être corrigée pour la même raison. Quoi qu'il en soit, la divulgation de ces informations donne à un attaquant potentiel un autre point de données à partir duquel effectuer des recherches et potentiellement identifier des vulnérabilités.