OpenStudio est éditeur du logiciel libre Thelia

Thelia est un outil de création de sites e-commerce et de gestion de contenu en ligne basé sur Symfony 2. Vous trouverez dans cette section un aperçu de nos autres contributions libres et variées : développements logiciels, thèmes graphiques, tutoriels...

8 points clés pour améliorer la sécurité de votre site SPIP

SPIP est un logiciel reconnu comme sécurisé, qui sans être comparable en terme de popularité à d’autres CMS plus internationaux, bénéficie de mises à jour régulières et dispose d’une communauté active de développeurs.

Même si l’installation par défaut de ce logiciel convient pour la majorité des projets éditoriaux, il faudra parfois faire certains ajustements en fonctions de la spécificité de votre projet :
- confidentialité de certaines données,
- exposition particulière du site aux attaques liée à sa notoriété,
- développement de squelettes avancés.

Voici 8 points clefs pour vous guider dans l’amélioration de la sécurité de votre site SPIP.

1. Disposer d’une version de SPIP à jour

La première vérification - et la plus importante ! - est bien sûr de disposer d’une installation (SPIP et plugins) qui soit à jour des mises à jours de sécurité. Si vous n’avez pas la possibilité de faire une mise à jour, vous pouvez installer ou mettre à jour l’écran de sécurité.

Vous pouvez vous tenir informé des différentes mises à jour de SPIP :
- en consultant régulièrement la section dédiée sur spip-contrib.net
- en vous abonnant à la liste de diffusion spip-ann
- en suivant @spip sur twitter
- en regardant le pied de page de l’espace privé

Vous pouvez vous tenir informé des différentes mises à jour de plugins :
- en installant le plugin step.

2. Vérifier le paramétrage d’Apache

Nous n’entrerons pas dans le détail de la configuration du serveur, toutefois veillez à bloquer le parcours des répertoires dans apache et à désactiver l’affichage des erreurs et warnings php, afin d’éviter des attaques de type Full Path Disclosure.

Il est important également d’empêcher l’affichage des squelettes, car les squelettes personnalisés peuvent contenir de nombreuses failles de sécurité, comme nous le verrons plus bas.

Pour cela, créez un fichier .htaccess dans votre dossier /squelettes contenant :

  1. <Files *.html>
  2. Deny from all
  3. </Files>

Il est important d’adapter également les permissions sur les dossiers utilisés par SPIP.

3. Masquer le type de CMS utilisé

Il est illusoire de penser masquer totalement les indications du type de CMS utilisé [1], mais quelques rapides actions et paramétrages rendront sa détection plus difficile.

Vous pouvez commencer par supprimer les fichiers .txt se trouvant à la racine du site, lesquels informent sur la version de SPIP CHANGELOG.TXT,INSTALL.TXT, ...).

Il peut être judicieux également de renommer le dossier /ecrire avec un nom personnalisé, puis de limiter les entêtes http générées par SPIP - qui informent sur les plugins installés et leurs versions respectives - , en ajoutant la directive suivante dans /config/mes_options.php :

  1. <?php
  2. $spip_header_silencieux = 1;
  3. ?>

Enfin, activez une des réécriture d’url proposée par SPIP, et complétez celle-ci pour les pages plan, backend, ... tel qu’indiqué dans ce tutoriel.

4. Mettre en place une politique de sécurité

La sécurisation de votre site passe impérativement par la mise en place d’une politique de sécurité au niveau des rédacteurs et des administrateurs. Par exemple, imposez des mots de passe complexes aux auteurs. Pour vous en assurer, vous pouvez mettre en place le plugin Plugin mot de passe compliqué. En outre, n’utilisez pas de compte commun à plusieurs utilisateurs.

Parfois il est pertinent d’affiner les autorisations de SPIP pour les différents types de profils, avec le plugin Autorité.

Enfin, les forums étant une source facile de spam, placez vos forums en "modération à priori", et utilisez un plugin anti-spam.

5. Contrôler l’accès aux documents de IMG

Par défaut dans SPIP, tous les documents joints aux articles sont accessibles par tout le monde, par une url directe du type http://monsitespip.com/IMG/pdf/monpdfconfidentiel.pdf

Il ne suffit pas de ne pas lister un document pour qu’il soit caché. Ce mode de fonctionnement est souvent mal connu des webmaster, et les documents confidentiels se trouvent indexés dans les moteurs de recherche [2].

Il faut vraiment avoir conscience que pour qu’un document ne soit visible que par des personnes autorisées à le consulter, il faut mettre en place un contrôle d’accès au document.

Pour cela, il faut installer le plugin Acces restreint et activer la protection des documents de SPIP (paragraphe V)

6. Désactiver les squelettes par défaut et plugins inutilisés

SPIP est basé sur un système de surcharge. Lorsqu’un fichier (squelette, ou document) est appelé dans l’url ?page=mapage ou par la balise #CHEMIN, SPIP parcours l’arborescence dans un certain ordre et prend le premier fichier du nom recherché qu’il trouve. La lecture par défaut est la suivante : [3] :

- squelettes
- plugin B dépendant du plugin A
- plugin A
- squelettes-dist
- prive
- ecrire
- .

Il faut bien comprendre que si un squelette quelconque de cette arborescence [4] n’est pas "désactivé" (i.e. surchargé par un squelette du même nom et vide), il est appelable directement dans l’url.

La solution la plus simple pour désactiver ces squelettes inutilisés est d’installer le plugin SPIP reset (ou Zpip reset, l’équivalent si vous utilisez les squelettes Zpip)

Vérifiez surtout le contenu du fichier robots.txt généré par spip (?page=robots.txt) ainsi que le fichier sitemap.xml (généré par ?page=sitemap.xml). Comme tout squelette SPIP, il vous est possible de les surcharger dans votre squelette (sitemap.xml.html et robots.txt.html). Si des pages ont été indexées par erreur par google, vous pouvez en demander le retrait.

Enfin, évitez de laisser actifs des plugins que vous n’utilisez pas.

Une astuce consiste à s’abonner sur l’alerte google de votre site pour vérifier les nouvelles pages indexées.

7. Être rigoureux dans l’écriture des squelettes

Le plus important concernant la sécurité de votre site SPIP se situe au niveau de l’écriture des squelettes. Nous avons vu précédemment qu’une bonne pratique consiste à empêcher l’accès aux squelettes. Toutefois voici quelques règles simples qui vous éviteront beaucoup de déconvenues !

Le point essentiel est d’éviter autant que possible l’utilisation de code PHP dans les squelettes, car on augmente significativement les risques d’injection de code arbitraire ! [5].

Typiquement le code suivant dans un squelette est à proscrire absolument :

  1. <?php
  2. $variable = '#MABALISE';
  3. ?>

Par défaut dans spip lorsqu’une balise n’est pas reconnue, elle est considérée comme un paramètre _request. Ainsi en passant dans l’url :

  1. http://votresite.com/?page=mapage&mabalise=';phpinfos();$variable2='

on obtient l’injection de code PHP suivante :

  1. <?php
  2. $variable = '';phpinfos();$variable2='';
  3. ?>

Dans certains cas, où l’on est contraint d’utiliser du php dans les squelettes, il faut protéger toutes les balises avec une fonction comme addslashes().
Le squelette d’exemple ci-dessus serait alors protégé contre les injections :

  1. <?php
  2. $variable = '[(#MABALISE|addslashes)]';
  3. ?>

Il est possible d’automatiser ce traitement en ajoutant dans le fichier /config/mes_options.php la ligne suivante (à dupliquer pour chaque balise ou champ de table à protéger) [6] :

  1. <?php
  2. $table_des_traitements['MABALISE'][]= 'addslashes(%s)';
  3. ?>

Comme nous l’avons vu précédemment, il est possible d’appeler directement par url n’importe quel squelette de l’arborescence SPIP. Or, vos noisettes [7] ne sont pas supposées être appelées directement ! Veillez donc à placer les noisettes SPIP dans des sous répertoires.

Enfin, il faut faire attention lors de l’utilisation de balises brutes #MABALISE** [8] car elles peuvent être un moyen de réaliser des attaques de type Cross Site Scripting [9].

8. Réaliser un audit régulier

Forcez-vous à réaliser ou faire réaliser régulièrement un audit de votre site, c’est une bonne manière de remonter des vulnérabilités avant qu’elles ne soient exploitées par d’autres.

9 Messages

  • Sur le point 3, je dois avouer que je n’aime pas la sécurité par l’obscurité.

    De plus, quelqu’un de déterminé pourrait juste charger des fichiers js ou css spécifiques ayant changé entre 2 versions de SPIP pour reconnaître la version utilisée…

  • C’est pourtant vrai.
    Le mieux c’est que tu fasses le test tel qu’indiqué dans cet article.
    Créer un squelette squelettes/testbalise.html qui contient :

    puis appelle la page ?page=testbalise&mabalise=toto
    ou encore ?page=testbalise&mabalise=toto<script>alert('coucou');</script>
    Dans l’attente de ton retour.

  • L’exemple du point 7 est totalement inadapté.
    En effet, l’explication donnée est totalement fausse : "Par défaut dans spip lorsqu’une balise n’est pas reconnue, elle est considérée comme un paramètre _request."

  • Bonjour,
    pour info, des nouvelles version (une par branche de maintenance) sont sorties ce matin : c’est l’occasion de mettre vos site SPIP à jour !!!
    .Gilles

  • Il y a également beaucoup de discussions sur SPIP et les permissions d’accès aux dossiers en 777.
    Certains répertoires (config, IMG, local, tmp etc...) sont paramétrés pour avoir des permissions d’accès en 777.
    Ne pourrions-nous pas sécuriser plus ou modifier define(’_SPIP_CHMOD’, 0777) ?

  • SPIP propose le filtre

    |textescript

    pour sécurisé les parties PHP contenue dans les squelettes plus "complet" que la fonction addslashes.
    http://www.spip.net/fr_article4281.html

  • Un élément qui peut poser problème dans les mises à jour par versions stables, c’est qu’il peut y avoir des délais entre la correction d’un bug et la sortie de la prochaine version. SPIP 2.1.12 est sortie en novembre 2011 (http://www.spip.net/fr_article2670.html)
    C’est un peu comme sous Linux, genre Debian, où le mécanisme d’installation automatique est pratique mais pas satisfaisant pour garantir la sécurité (il n’y a qu’à voir la version actuelle du paquet de phpmyadmin sur Squeeze pour s’en rendre compte)
    Pour les maniacs de la sécurité, la meilleure option est de mettre à jour régulièrement SPIP sur la branche de maintenance (soit par SVN, soit par l’archive quotidienne http://files.spip.org/spip/dev/SPIP-branche-2.1.zip) - en tout cas au moins à chaque fois qu’une faille XSS est corrigée, comme c’était le cas cette nuit (http://core.spip.org/projects/spip/repository/revisions/19253)

  • Effectivement, c’est un oubli, je vais mettre à jour l’article : la mise à jour de l’écran de sécurité est une solution pratique et efficace pour sécuriser rapidement son site spip après parution d’une alerte sécurité.

    Mais cela reste une solution provisoire, et il faut garder à l’esprit que l’écran de sécurité n’agit que sur les variables GET et POST et que dans certains cas, il est possible de le contourner (l’attaque est tordue, je l’accorde... ) mais c’est le cas notamment pour la faille critique corrigée en 2.1.8.

  • Pour ceux qui ne savent pas comment mettre à jour leur site (c’est parfois compliqué pour un utilisateur néophyte), je conseille plutôt d’installer l’écran de sécurité le plus à jour : http://www.spip.net/fr_article4200.html
    Il règle toutes les failles de sécurité connues à ce jour, toutes versions de SPIP confondues.