je me dis : pourquoi ne pas afficher cette information qu'aux seuls utilisateurs habilités, par exemple dans l'espace privé, ou aux seuls admins ? Mais en l'occurrence, pas à tout le monde... (en gros, il y a "utilisateurs de SPIP et utilisateurs de SPIP" : des utilisateurs lambada^W lambda, et des utilisateurs avancés - qui eux ont besoin de connaitre expressément la version de l'écran de sécurité...)
J’ai compris l’argument de Cédric (et d’autres) :
Ce n’est pas une sécurité de masquer ce type d’information. Et la laisser peut rendre de nombreux services.
A partir du moment où les utilisateurs avancés peuvent masquer l’information s’ils le souhaitent (c’est une ligne à changer), il n’y a pas de problème.
Un point à souligner : l’écran de sécurité n’est pas visible à chaque hit, contrairement aux autres éléments de SPIP. Donc si l’utilisateur veut masquer le plus possible ses faiblesses, il faut qu’il commence par là
Du coup si l'affichage est limité aux admins, voire aux webmestres
est-ce qu'il ne mérite pas d'être plus visible (quitte à le garder
dans le pied de page mais a afficher en + une annonce de type
compagnon)
Non mais stop :
1/ l'affichage dans l'espace privé est déjà prévu, il est dans le pied de page pour tous les utilisateurs
2/ Le but d'annoncer la version à la demande c'est pour permettre le support des utilisateurs sans avoir à être connecté à l'admin. Donc il n'y a aucune raison de toucher à ça, ça ne gêne personne, ça n'est pas une faille de sécurité, et ça rend service.
J'ai vu plusieurs sujets sur la liste ces derniers temps au sujet de Spip et
la sécurité.
Je travaille en ce moment sur un site avec un client particulièrement à
cheval sur ces sujets là.
Le site est fait avec Spip 3.0.17 et l'écran de sécurité 1.1.19.
Il a fait passer des tests avec son outil (HP Fortify) et il trouve un
nombre important de faille de sécurité : 1583 failles critiques et 579
importantes.
Ce grand nombre de faille s'explique en partie parce qu'une même faille peut
être exploitée à plusieurs endroits dans le code... ce qui, au final, réduit
pas mal le nombre de faille.
Je ne connais pas HP Fortify et je ne sais pas trop comment il fait pour
analyser le site mais certain d'entres vous y sont peut-être plus familier
et ont déjà été confronté à ce problème ?
A-t-on vraiment un risque important de sécurité avec Spip ou est-ce HP
Fortify qui est un peu trop parano ?
Pour ceux que ça intéresse vous pouvez télécharger le rapport de sécurité
ici : http://bit.ly/spip-secu
Si vous arrivez à décrypter ce fichier et comprendre s'il y a vraiment
danger, je suis preneur
Il a fait passer des tests avec son outil (HP Fortify) et il trouve un
nombre important de faille de sécurité : 1583 failles critiques et 579
importantes.
Ce grand nombre de faille s'explique en partie parce qu'une même faille peut
être exploitée à plusieurs endroits dans le code... ce qui, au final, réduit
pas mal le nombre de faille.
Je ne connais pas HP Fortify et je ne sais pas trop comment il fait pour
analyser le site mais certain d'entres vous y sont peut-être plus familier
et ont déjà été confronté à ce problème ?
A-t-on vraiment un risque important de sécurité avec Spip ou est-ce HP
Fortify qui est un peu trop parano ?
D'après les commentaires de l'article suivant, cet outil a tendance à générer un paquet de faux positifs dans ses résultats :
"One thing with Fortify is that you will get A LOT of false positives."
"Fortify is incredibly easy to fool."
"I have to agree with DrDugong. It emits too many false positive."
Pour info, si vous trouvez des failles de sécurité dans SPIP et que vous arrivez à les exploiter, il faut les signaler à l'adresse suivante spip-team @ rezo.net
Le site de l'Agence nationale de la sécurité des systèmes
d’information http://www.ssi.gouv.fr/ est en SPIP si ça peut rassurer
ton client.
Le meilleur moyen d'assurer la sécurité d'un site utilisant un CMS
s'est de mettre en place les mises à jour dès leur parution. Il faut
surtout qu'il ait un contrat de maintenance qui prévoir ceci.
> 1/ l'affichage dans l'espace privé est déjà prévu, il est dans le pied de page pour tous les utilisateurs
Merci pour l'info.
- effectivement, c'est affiché dans les versions récentes de SPIP (ça n'apparait pas dans SPIP 2.1.12, il me semble).
- pour les personnes qui comme moi ont un écran trop petit, penser à descendre via l'ascenseur vertical pour consulter le dit pied de page.
> 2/ Le but d'annoncer la version à la demande c'est pour permettre le support des utilisateurs sans avoir à être connecté à l'admin. Donc il n'y a aucune raison de toucher à ça, ça ne gêne personne, ça n'est pas une faille de sécurité, et ça rend service.
Merci pour ce point de vue (point de vue qui accessoirement n'était pas du tout le mien...).
> 2/ Le but d'annoncer la version à la demande c'est pour permettre le
support des utilisateurs sans avoir à être connecté à l'admin. Donc il
n'y a aucune raison de toucher à ça, ça ne gêne personne, ça n'est pas
une faille de sécurité, et ça rend service.
Merci pour ce point de vue (point de vue qui accessoirement n'était pas
du tout le mien...).
Pour info, quelqu'un de déterminé peut savoir la version de n'importe quel CMS juste en comparant les éléments publics de ce CMS (CSS, images, js) avec ceux de telle ou telle version.
En masquant la version de SPIP, on complique le support, mais pas les les attaques.
Il y a nettement moins de failles connues sous SPIP que tous les autres CMS que je connais, d’après http://www.exploit-db.com/ - et pourtant SPIP est certainement le plus ancien.
C’est peut-être un argument à avancer – même si ça peut être biaisé par la faible utilisation de SPIP dans l’univers du web (et du coup le faible intérêt des hackers).
Cela dit, il y a des éléments dans le rapports qui méritent de s’y pencher. Peut-être des patchs de sécurité à venir !
Merci Bruno pour ce lien, ça donne de bons arguments sur la pertinence des
tests faits par HP Fortify.
Il y a l'air d'avoir effectivement beaucoup de Faux positifs et qu'il est
facile de tromper le test.
Du coup il faut peut-être plus voir ce rapport comme un support, un guide
pour améliorer la sécurité d'un site que comme un vrai audit de sécurité.
Valéry-Xavier, tu as bien raison.
Le client avait laissé son ancien site bien trop longtemps sans mise à jour de sécurité, c'est pour cela qu'il s'est fait hacker et qu'il est maintenant sensibilisé au sujet... peut être un peu trop, il ne faut pas non plus devenir parano.
Par contre, l'argument du site de l'Agence nationale de la sécurité des systèmes d’information en SPIP... comme on dit que ce sont souvent les cordonniers les plus mal chaussé, je ne suis pas sûr que ça va marcher
Merci pour le lien, c’est sûr qu’il n’y a pas l’air d’avoir beaucoup de failles de sécurité récentes indiquées pour Spip. Ce qui laisserai effectivement penser qu’il y a beaucoup de Faux positifs dans le rapport de HP Fortify. Je pense en effet que la majorité des problèmes indiqués sont réglés grâce à l’écran de sécurité. Par contre comment en être certain, c’est une autre question J
Maintenant ton dernier commentaire m’inquiète un peu plus. Aurais-tu repéré quelque chose de louche ?
Je peux toujours essayer de faire débloquer un budget auprès de mon client pour faire travailler quelqu’un sur d’éventuelles failles et montrer que le rapport HP Fortify ne contient que des Faux positifs.
Rien d'alarmant, en épluchant le rapport je me suis demandé comment est-ce
qu'il pouvait interpréter que tels enchainements d'instructions pouvaient
entrainer une faille, et je n'ai rien trouvé. Si ce n'est qu'il semble
exploiter des trucs très généraux mais qui sont sans faille vu le contexte.
Du coup je me suis intéressé au dossier "Code Testing" publié par la
communauté d'owasp.com, dans lequel ils ne s'intéressent pas trop aux
outils de test automatiques qui sont trop génériques alors que les failles
sont souvent liées à la logique même du logiciel. Leurs auteurs
recommandent même de ne pas s'appuyer dessus pour essayer de trouver des
failles (et encore moins de démontrer que le logiciel est sécurisé) - mais
plutôt d'utiliser cette énergie dans une approche assez systématique (en
fait ils en détaillent plusieurs).
Tu peux télécharger le guide complet ici : https://www.owasp.org/index.php/Category:OWASP_Testing_Project
En tout cas si ton client est prêt à payer un expert en sécurité web pour
se plonger dans la logique du code de SPIP, et essayer d'y trouver quelques
pépites, je pense que ça intéressera tout le monde et que le résultat sera
nettement meilleur pour ton client et la communauté.
Mon client a l’air disposer à débloquer un budget pour analyser les erreurs critiques du rapport et montrer qu’il ne s’agit en effet que de faux positifs.
Gilles as-tu une idée du temps et du coût d’une telle mission ?
Concernant le profil de l’expert en sécurité, j’imagine que ça serait mieux s’il connaissait bien Spip.
L’un d’entre vous serait-il intéressé pour cette mission ou connaissez vous quelqu’un qui pourrait l’être ?
Si le client veut vérifier les 1583 failles de sécurité, ça va prendre un bon bout de temps. Quand à savoir s’il faut que ce soit quelqu’un qui connaisse SPIP, pour ce type de vérification, cela ne me semble pas essentiel. Un bon codeur arrivera à s’y retrouver au bout d’une ou deux journée de mise en jambe dans le code. Je ne pense pas qu’il faille compter moins d’une semaine d’intervention.
