Par défaut, SPIP en dit long sur sa version et les plugins utilisés.
Vu que les failles sont connues (il suffit par exemple de chercher “XSS” dans les logs des commits), est-ce que cela ne présente pas un risque trop important pour être laissé tel quel ?
Franchement, qui à part un hacker peut être intéressé par ce type d’information ?
Je sais que ça sert pour les stats que fait Cédric sur les versions, mais je pense que diffuser ce type d’information devrait être un acte volontaire.
Il faudrait au moins que ça puisse être clairement paramétrable depuis l’interface privée. L’utilisateur moyen ne va pas chercher une variable PHP pas trop documentée…
En tout cas, ça peut être très utile pour une prospection commerciale :)=
Si des gens mettent à jour leur SPIP pour cacher les headers, ils
auraient pu aussi le mettre à jour pour combler les failles.
L'argument est rigolo mais pas du tout logique.
Le temps continuera à passer, de nouvelles versions continueront à
sortir... Des gens actualiseront ou feront une install fraîche
(incluant entre autres la modif proposée), mais n'actualiseront pas
forcément assidûment à chaque fois... L'idée c'est que ce soit dans le
code tout court.
Autrement dit, le comportement proposé correspondra à un SPIP à jour au
début, mais plus le temps passera et moins ça sera vrai, et plus ça
sera utile d'avoir ce code.
je pensais à un autre aspect aussi :
un utilisateur qui laisse son site SPIP sous une vieille version a de fortes chances de faire pareil pour les autres softs qui sont sur son site (forums, etc…) - soit par inconscience, soit par manque de compétence.
Et je ne crois pas que les autres applis web aillent aussi loin que SPIP dans la déclaration des composants utilisés. Je veux bien qu’on fasse exception, mais il faudrait que ce soit justifié, non ?
C'est utile pour le debug et quand on veut aider les gens.
Par ailleurs, si tu veux tester un trou de sécurité X, pas besoin de
contrôler le numéro de version : tu envoies l'exploit correspondant au
site, et tu regardes si ça marche. C'est donc totalement illusoire
comme protection que de tenter de masquer le numéro de version. Lequel
est par ailleurs révélé de plein de manières (ne serait-ce que le code
source de la page de login, ou le contenu de spip_style.css etc).
* Gilles VINCENT tapuscrivait, le 02/09/2011 01:07:
Par défaut, SPIP en dit long sur sa version et les plugins utilisés.
Vu que les failles sont connues (il suffit par exemple de chercher "XSS"
dans les logs des commits), est-ce que cela ne présente pas un risque trop
important pour être laissé tel quel ?
Une petite recherche de "sécurité par l'obscurité" devrait te convaincre que ça ne sert à rien (cf aussi réponse de Fil).
Au passage, apache aussi diffuse par défaut sa version.
Si c’est utile pour le debug, autant que ça soit une option activable au moment du debug.
C’est comme pour PHP, la commande phpinfo() sert justement à cela.
Certes Apache donne bien son numéro, mais il n’indique pas pour autant tous les modules qui sont activés.
Là ce qui m’inquiète plus c’est pas tellement SPIP mais les plugins pas mis à jour, pas maintenus, ou développés par des gars qui codent avec le dos de la cuillère etc… On peut toujours envoyer des exploits en aveugle mais si le site indique dès le départ qu’il est buggué c’est vraiment faciliter la vie de ceux qui veulent lancer les attaques
Et puis pardonnez ma comparaison osée, mais je vois peu de monde qui se promène dans la rue en exhibant la marque et la couleur de ses sous-vêtements - alors que là j’ai l’impression que c’est ce qui est attendu par défaut de tout(e) spipeur(se).
à jour, pas maintenus, ou développés par des gars qui codent avec le dos de
la cuillère etc..
Il y a là un élément intéressant... j'ai commis quelques plugins
(heureusement peu répandus) codés « avec le dos de la cuillère »... Je
ne suis sûrement pas le seul à l'avoir fait et dans la 20aine de
plugins que j'utilise il doit y avoir quelques trous de sécu qui
trainent. Béotien, je ne suis pas qualifié pour ça, mais on pourrait
mettre en place une équipe sécurité qui jette au moins un œil sur les
plugins très utilisés... Peut-être que ça existe déjà ? Resterai le
problème des trous dans les plugins moins utilisés (comme les miens
!)...
Si c'est utile pour le debug, autant que ça soit une option activable au moment du debug.
C'est comme pour PHP, la commande phpinfo() sert justement à cela.
Certes Apache donne bien son numéro, mais il n'indique pas pour autant tous les modules qui sont activés.
Là ce qui m'inquiète plus c'est pas tellement SPIP mais les plugins pas mis à jour, pas maintenus, ou développés par des gars qui codent avec le dos de la cuillère etc.. On peut toujours envoyer des exploits en aveugle mais si le site indique dès le départ qu'il est buggué c'est vraiment faciliter la vie de ceux qui veulent lancer les attaques
Encore une fois cela ne change RIEN.
Si je sais qu'il y a une faille dans le plugin X il est aussi rapide et efficace de tester directement l'attaque sur ton site que de regarder l'en-tete pour savoir si l'attaque va marcher.
Sans compter qu'en bon attaquant je sais bien que tout le monde copie colle le code GPL pour ses trucs persos et que même si tu as pas le plugin X tu as des chances d'avoir la faille
parce que tu as copié un bout du code de X pour faire un fork à toi.
Donc cacher cette information n'apporte AUCUN gain de sécurité et ne fera que rendre plus compliqué plein d'opérations positives comme savoir si un plugin est utilisé ou pas pour le maintenir, ou pour déployer un patch de sécu dans l'écran, ou pour aider à debug un utilisateur avec son SPIP est qui arrive à peine à te dire ce qui est installé dessus.
Et puis pardonnez ma comparaison osée, mais je vois peu de monde qui se promène dans la rue en exhibant la marque et la couleur de ses sous-vêtements - alors que là j'ai l'impression que c'est ce qui est attendu par défaut de tout(e) spipeur(se).
Encore une fois, masquer les headers n'empêche absolument pas de recenser les plugins d'un site, qui sont 90% du temps installés dans un répertoire du nom de celui sur la zone ou de celui du zip, dans plugins/ ou dans auto/ et qu'il est donc très facile de récupérer le fichier plugin.xml dans tous ces cas là, ce qui est tout aussi informatif.
De même que la détection d'un plugin peut se faire par la présence de sa css etc ...
