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

Cette contribution ou ce plugin est en phase de test. Des bugs peuvent subsister. N’hésitez pas à les signaler dans le forum ci-dessous.

Il arrive que pour des raisons de sécurité, on ait envie ou besoin de modifier certaines en-têtes HTTP transmises par le serveur. Ce plugin a pour but de faciliter ces modifications.

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;

Discussion

2 discussions

  • 1

    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 :

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

    Répondre à ce message

  • 9

    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 :

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

    • 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 :

  • Désactiver tous les plugins que vous ne voulez pas tester afin de vous assurer que le bug vient bien du plugin X. Cela vous évitera d’écrire sur le forum d’une contribution qui n’est finalement pas en cause.
  • Cherchez et notez les numéros de version de tout ce qui est en place au moment du test :
    • version de SPIP, en bas de la partie privée
    • version du plugin testé et des éventuels plugins nécessités
    • version de PHP (exec=info en partie privée)
    • version de MySQL / SQLite
  • Si votre problème concerne la partie publique de votre site, donnez une URL où le bug est visible, pour que les gens puissent voir par eux-mêmes.
  • En cas de page blanche, merci d’activer l’affichage des erreurs, et d’indiquer ensuite l’erreur qui apparaît.

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.

Qui êtes-vous ?
[Se connecter]

Pour afficher votre trombine avec votre message, enregistrez-la d’abord sur gravatar.com (gratuit et indolore) et n’oubliez pas d’indiquer votre adresse e-mail ici.

Ajoutez votre commentaire ici

Ce champ accepte les raccourcis SPIP {{gras}} {italique} -*liste [texte->url] <quote> <code> et le code HTML <q> <del> <ins>. Pour créer des paragraphes, laissez simplement des lignes vides.

Ajouter un document

Suivre les commentaires : RSS 2.0 | Atom