Masquer les en-têtes (Headers) HTTP avec Update Headers - commentaires

Masquer les en-têtes (Headers) HTTP avec Update Headers

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 :

# Supprimer l'entête ComposedBy & autres ref à SPIP
Header unset Composed-By
Header unset X-Powered-By
Header unset X-Spip-Cache

Masquer les en-têtes (Headers) HTTP avec Update Headers

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

Masquer les en-têtes (Headers) HTTP avec Update Headers

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.

Masquer les en-têtes (Headers) HTTP avec Update Headers

@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.

Masquer les en-têtes (Headers) HTTP avec Update Headers

@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…

Masquer les en-têtes (Headers) HTTP avec Update Headers

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

Masquer les en-têtes (Headers) HTTP avec Update Headers

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...

Masquer les en-têtes (Headers) HTTP avec Update Headers

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 :

### Interdire l'accès au fichiers SPIP
# RewriteRule ^svn[.]revision$ - [F]
# RewriteRule ^local/config.txt$ - [F]
# RewriteRule ^squelettes/(.*).html$ - [F]

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...

Masquer les en-têtes (Headers) HTTP avec Update Headers

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.

Masquer les en-têtes (Headers) HTTP avec Update Headers

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é.

Masquer les en-têtes (Headers) HTTP avec Update Headers

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.

Masquer les en-têtes (Headers) HTTP avec Update Headers

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.