stormtrooper
2019-08-13 13:34:53 UTC
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'en-tête de licence intact, y compris le numéro de version.
Notre client a signalé l'exposition de la combinaison produit et version comme un risque de sécurité. Curieusement, 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 les numéros de version en exécutant du code dans Firebug ou dans la Developer Console de Chrome.
Dans quelles circonstances cette "mauvaise configuration de sécurité" ( https://www.owasp.org/index. php / Top_10-2017_A6-Security_Misconfiguration) s'appliquent à l'affichage du numéro de produit et de version? Et comment pouvons-nous résoudre ce problème sans violer la licence jQuery?
Je pense que vous avez une erreur logique en ce que la divulgation d'informations est assimilée à une mauvaise configuration de sécurité.Ils ne sont en aucun cas identiques ou liés.
"* Curieusement, la version bootstrap dans le même fichier n'est pas signalée comme un risque de sécurité. *" Ils ont peut-être repéré au hasard le numéro de version de jQuery et l'ont signalé.Ou ils pourraient penser qu'il est redondant de pinailler chaque numéro de version qu'ils ont trouvé.Ou leur outil automatisé vient de repérer celui de jQuery.Tout comme les logiciels ne sont jamais exempts de bogues parce que le programmeur ne pense pas à tous les cas extrêmes ou ne connaît pas chaque bizarrerie (ou n'a peut-être pas assez de temps pour le faire), le pentesting est également une entreprise inexacte.
Supprimer le numéro de version du fichier de licence ne vous aiderait pas de toute façon, car un attaquant peut simplement vérifier manuellement la version que vous utilisez.
@MechMK1 pas si vous ajoutez du code inaccessible (comme `if (true === false) {}`) ou des espaces aléatoires quelque part / partout, alors leurs correspondants automatiques ne pourraient pas correspondre définitivement à une version.
@MonkeyZeus Si vous utilisez une correspondance exacte naïve, vous auriez raison.Cependant, si vous vérifiez un degré de similitude, de légères modifications apportées à jQuery 3.1.7 ressembleront toujours à 99,8% à jQuery 3.1.7.
@MechMK1 Il a été mentionné d'innombrables fois que si un attaquant vous cible spécifiquement, rien de tout cela n'a d'importance, surtout quand vous parlez de code envoyé au client comme JS, mais si vous essayez simplement d'éviter les script kiddies alors même la moindre obscurité "aide".La vraie mauvaise configuration de la sécurité utilise une version vulnérable.Même si vous n'utilisez pas une version vulnérable, il est extrêmement simple de faire en sorte que le navigateur utilise une version vulnérable.Honnêtement, si votre site Web est vulnérable à cause de JS, vous faites quelque chose de mal du point de vue de la sécurité.
@MonkeyZeus Oui, je suis conscient, mais ce n'était pas vraiment le point.Les Script Kiddies utilisent des outils automatisés bien conçus, pas des outils auto-écrits mal conçus.Chaque analyseur d'applications Web de base sera en mesure d'identifier une version modifiée de jQuery, donc tenter de l'obscurcir entraînera simplement des problèmes et aucun gain de sécurité.Bien que j'aimerais savoir comment vous amèneriez un navigateur à utiliser une version vulnérable de jQuery, si le site inclut une version sans vulnités connues.
@MechMK1 Copier + Coller + Entrer dans la fenêtre de votre console: `var script = document.createElement ('script');script.type = 'texte / javascript';script.src = 'https://ajax.googleapis.com/ajax/libs/jquery/1.2.3/jquery.min.js';document.head.appendChild (script);alert (jQuery.fn.jquery); `
Passer du temps à essayer de cacher les versions des bibliothèques côté client, au lieu de passer du temps à résoudre de vrais problèmes de sécurité, vous rend potentiellement plus vulnérable.
@MonkeyZeus Oui, mais vous ne pouvez le faire qu'à vous-même, pas aux autres.Vous ne pouvez pas, par exemple, me pousser à utiliser une version vulnérable de jQuery.
Je ne vois aucune indication sur https://jquery.org/license/ que le numéro de version doit rester intact.Il dit que l'en-tête du copyright doit ... tant que vous avez le `Copyright 2005, 2014 jQuery Foundation, Inc. et d'autres contributeurs;Publié sous la licence MIT;http: // jquery.org / license` Je ne m'attendrais pas à ce qu'ils sourcillent.
@ceejayoz Comme mentionné précédemment, cela ne vous aiderait de toute façon pas à masquer la version.
@MechMK1 Bien sûr, mais cela aiderait OP à retirer le scanner de sécurité du client.
@ceejayoz "Corriger" les problèmes pour empêcher le scanner de se plaindre est l'une des ** pires ** choses que vous puissiez faire.Bien sûr, supprimer une version dans un fichier de licence ne suffit pas, mais c'est une approche fondamentalement erronée.Des choses comme celles-ci sont la raison pour laquelle le bogue Debian PRNG est apparu.
@MechMK1 Tant qu'OP a une version sûre de jQuery, le résultat du scanner ici est un * faux positif *.Je ne préconise pas de dissimuler une version non sécurisée;Je dis que la divulgation de version signalée peut être traitée en toute sécurité de cette façon.
@ceejayoz Oui, c'est vrai, et dans ce cas précis, je n'y verrais pas de problème.Mais je dirais qu'en général, il vaut mieux apprendre à étiqueter les rapports comme des faux positifs, plutôt que de se précipiter et de mettre en œuvre une «solution».
@MechMK1 Très bien, je peux être d'accord avec cela.