Qu’est-ce qu’une entête HTTP ?
Lorsqu’un fichier est appelé (Par un navigateur, par exemple), le code qu’il renvoit est séparé en deux parties : l’entête (head) et le contenu (body).
L’entête contient des informations sur le fichier (Taille, jeu de caractères utilisé, etc), ainsi que des informations sur le serveur. Elle peut également contenir des informations de mise en cache.
Pourquoi vouloir les masquer / les changer ?
Cette entête est parfois trop bavarde. Par défaut, elle renseigne sur la version d’Apache installée sur le serveur, ainsi que la version de PHP. Avec SPIP, elle renseigne également sur la version du site utilisée, ainsi que de la liste des plugins installés !
Par exemple, au moment où j’écris cet article, les entêtes renseignées dans SPIP-Contrib sont les suivantes :
Composed-By:SPIP 3.0.14 @ www.spip.net + spip(3.0.14),compagnon(1.4.1),dump(1.6.7),images(1.1.7),forum(1.8.30),jqueryui(1.8.21),mediabox(0.8.4),mots(2.4.11),organiseur(0.8.10),petitions(1.4.5),porte_plume(1.12.4),revisions(1.7.7),safehtml(1.4.1),sites(1.7.12),stats(0.4.23),themes(1.2.0),urls(1.4.15),vertebres(1.2.2),ck(1.1.9),crayons(1.17.0),entravaux(3.1.15),facteur(3.0.7),gravatar(1.5.1),memoization(1.4.2),nospam(1.5.6),zengarden(2.5.3),ancresdouces(1.4.3),autorite(0.10.0),boussole(2.5.2),boutonstexte(2.0.0),coloration_code(0.8.2),fulltext(0.7.1),jd(0.1.0),player(2.1.5),messagerie(2.0.1),notation(2.0.6),notifications(3.1.0),openid(1.2.0),orthotypo(1.3.5),simplog(1.0.4),socialtags(1.0.4),spip_bonux(3.0.5),squelettes_par_rubrique(1.1.1),together(0.3.0),twitter(1.1.3),univers(0.2.12),z(1.7.25),comments(3.2.7),nuage(4.0.2),saisies(1.38.6),opensearch(0.2.0),ppp(1.0.5),iterateurs(0.6.1),queue(0.6.6),breves(1.3.6),compresseur(1.8.7)
Connection:Keep-Alive
Content-Length:47828
Content-Type:text/html; charset=utf-8
Date:Fri, 31 Jan 2014 16:38:51 GMT
Keep-Alive:timeout=1, max=100
Last-Modified:Fri, 31 Jan 2014 16:38:51 GMT
Server:Apache/2.2.16 (Debian) DAV/2 SVN/1.6.12 Phusion_Passenger/2.2.11 PHP/5.3.3-7+squeeze14 with Suhosin-Patch mod_python/3.3.1 Python/2.6.6
Vary:Cookie,Accept-Encoding
X-Powered-By:PHP/5.3.3-7+squeeze14
X-Spip-Cache:86400
Comme on le voit aisément au début de l’export, toutes les infos sur SPIP sont ainsi divulguées. On constate donc que le site est maintenu à jour (À l’heure où j’écris cet article, la version 3.0.14 est la version stable la plus récente de SPIP), mais on a également la liste de tous les plugins et leurs versions (Qui semblent aussi être à jour).
Dans le cas d’un site SPIP moins souvent maintenu, connaître la version du CMS permettrait à un éventuel pirate d’enquêter sur cette version précise et de trouver une faille (Qui est sans doute même déjà documentée dans les changelogs même de SPIP). De même, des plugins non mis à jour pourraient se révéler plus vulnérables.
Il est donc important, dans un site en production, de pouvoir masquer ces informations.
Dans Update-Headers, deux cases à cocher permettent de masquer la version de SPIP (Composed-By) et la version de PHP utilisée (X-Powered-By).
Il est également possible, pour un utilisateur avancé, de modifier d’autres en-têtes ou d’en ajouter à sa convenance, avec le champ d’édition avancée.
Télécharger le plugin
Le plugin est pour l’instant hébergé sur GitHub, à l’adresse suivante : https://github.com/captain-torche/SPIP-Update-Headers
Son archive peut être téléchargée ici : https://github.com/captain-torche/SPIP-Update-Headers/archive/master.zip
Alternative sans utiliser ce plugin
Ce plugin permet de configurer le texte renvoyé par les headers des pages servies par SPIP. Si on veut seulement que la version de SPIP et la liste des plugins ne figure pas du tout dans les headers, tout simplement, il suffit d’ajouter la ligne suivante dans votre fichier mes_options.php :
<?php
$spip_header_silencieux = 1;
Discussions par date d’activité
2 discussions
je réitère mon propos : tout ceci n’a rien à voir(mais alors ce qui s’appelle rien de rien !) avec de la sécurité accrue pour un site spip.
Sinon, si le module Headers d’Apache est activé, il suffit de mettre dans le .htaccess les lignes suivantes pour supprimer les références aux backend :
Répondre à ce message
Il me parait illusoire de se croire en sécurité en masquant la version de SPIP et de ses plugins.
Si des attaques ont lieu, elles sont lancées par des bots qui testent des méthodes connues ou qui repèrent la version d’un CMS par d’autres signatures.
Je ne veux pas dire qu’il s’agit d’une sécurité absolue (Je vais modifier l’article en ce sens), mais que sur des sites moins suivis/mis à jour, ne pas indiquer qu’on utilise des versions obsolètes peut malgré tout être un plus.
Non justement c’est bien le problème : ça n’est pas un plus en terme de sécurité.
Ça ne fait que donner une illusion de sécurité : les bots d’attaque testent toutes les failles connues. Et les humains, ils utilisent un bot.
Ça n’empêchera donc jamais personne d’utiliser une faille de sécurité présente sur ton site.
Mais si en plus ça retarde la mise à jour de Spip ou des plugins au motif que la faille ne se voit pas, alors c’est carrément un moins en terme de sécurité.
En fait, j’ai un peu trop centré mon intro sur cette fonctionnalité alors qu’il permet d’éditer n’importe quelle entête. Mais effectivement, comme c’était un développement demandé par mon entreprise avec cette fonctionnalité obligatoire, je l’ai beaucoup (trop) mise en avant.
Je pense vraiment que le « problème » doit être abordé. On est tous d’accord pour dire que la sécurité par l’obscurité n’apporte rien, merci Kerckhoffs et la « maxime de Shannon ».
Mais partant de là, « l’adversaire connait le système », il faudrait peut être laisser le choix à l’utilisateur de mettre en libre accès ou non ces informations.
Ce soucis pourrait être réglé facilement sans touché à une ligne de code PHP, en laissant le choix à l’utilisateur, avec ces quelques lignes dans le fichiers .htaccess livré en standard avec SPIP :
C’est navrant de voir le nombre de portails propulsés par SPIP qui sont malheureusement mal codés et se retrouvent vulnérables à des injections de code PHP, SQL ou autre javascript qui deviennent triviales à exploiter parce qu’on peut facilement lire le code...
si un spip n’est pas à jour (ni par son écran de sécurité), on aura beau masquer tout et le reste, les failles resteront béantes et les scripts de test ou d’attaque resteront tout autant efficaces.
pour connaître la version d’un plugin, j’ai juste besoin d’un accès (http ou autre) à son fichier paquet.xml
et pour connaître la version d’un spip idem avec ecrire/paquet.xml
donc : bon...
A noter qu’il existe aussi la constante $spip_header_silencieux qui permet de ne pas dévoiler la version de spip et plugins. Et ceci sans aucun plugin ...
mes_options.php
$spip_header_silencieux = 1;
Documentation
http://www.spip.net/fr_article4648.html
@g0uz : ce que tu mentionnes c’est le cas où les développeurs mettent dans les squelettes en dur des requêtes SQL sans échappement, ou du PHP qui accède aux
$_GET
en les réinjectant dans le PHP sans précaution.Ces pratiques sont un non sens en terme de sécurité, à l’encontre de toutes les bonnes pratiques.
On peut certes les cacher sous le tapis avec la RewriteRule que tu proposes.
Mais c’est faire fi de l’objectif initial de SPIP : si les squelettes sont enregistrés dans des fichiers avec une extension
html
c’est justement dans le but de permettre à chacun de lire le code source d’un autre site et de s’en inspirer pour son propre site.C’est à dire de rendre le plus facile possible le partage et la diffusion du savoir faire.
La question revient finalement à savoir si SPIP doit plutôt faire en sorte de cacher les mauvaises pratiques de développement ou au contraire de faciliter la transmission du savoir faire. Tu devineras sans peine que c’est cette dernière option qui est conforme à l’objectif du projet…
@erational, il y a effectivement un double emploi, je ne connaissais pas ce réglage.
J’enlèverai la possibilité de masquer la version de SPIP dans une version ultérieure du plugin, et j’ajouterai un lien vers la documentation officielle.
Je parle bien de laisser le choix à l’utilisateur, on est bien d’accord sur les principes de partage et d’ouverture liés à ce CMS :-)
Les exemples donnés par denisb illustre bien la facilité avec laquelle on peut récupérer de l’information qui pourrait être utilisée à mauvais escient. Dans mon cas je parle plus d’attaque adaptée car accès, notamment, au code SPIP utilisé. A coté de ca, il existe je pense un grand nombre de sites, n’utilisant que du code SPIP, vulnérable à des XSS mais en oubliant les filtres adéquats.
Avertir l’utilisateur, lui laisser le choix de rendre ou non accessible ces données avec les procédures techniques adaptées me semble important. Après on peut discuter de la valeur par défaut :-p
Répondre à ce message
Ajouter un commentaire
Avant de faire part d’un problème sur un plugin X, merci de lire ce qui suit :
Merci d’avance pour les personnes qui vous aideront !
Par ailleurs, n’oubliez pas que les contributeurs et contributrices ont une vie en dehors de SPIP.
Suivre les commentaires : |