Philosophie

Lorsqu’elle découvre ou qu’on lui signale un « trou » de sécurité, l’équipe de développement de SPIP s’efforce de corriger le problème au plus vite dans sa version de développement et dans ses versions stables, afin de ne plus diffuser de code fautif.

Cependant, la majorité des utilisateurs n’a pas toujours le temps ou la possibilité de faire la mise à jour, et a tendance à peser le pour et le contre face au risque d’avoir, lors d’une mise à jour même minime, des incompatibilités ou des décalages avec le code testé et validé qu’elle a mis en ligne.

Pour un hébergeur, l’information concernant un problème de sécurité est également à double tranchant : d’un côté il ne souhaite pas laisser de « trou » sur un de ses sites hébergés, de l’autre il n’a pas toujours l’autorisation de modifier les sites. Et les mettre hors-ligne n’est bien souvent pas envisageable, sauf chez les hébergeurs cheap ou paranos.

L’écran de sécurité est là pour répondre à cette problématique. Il s’agit d’un fichier php unique et séparé de SPIP, que l’on peut mettre à jour indépendamment du reste du code, et qui est compatible avec toutes les versions de SPIP, même les plus anciennes.

Ce fichier ne se substitue pas a une véritable mise à niveau de votre version de SPIP, mais il peut permettre de bloquer certaines attaques en attendant une migration propre.

De fait, cet écran peut être activé au niveau du serveur sur l’ensemble des scripts php (SPIP ou pas), et garantit, s’il est à jour, que toutes les failles connues de quelque version de SPIP que ce soit sont impossibles à exploiter. D’où son nom d’« écran » : il se place entre le visiteur et SPIP, et vérifie que le visiteur n’est pas en train d’essayer d’exploiter une attaque connue.

Lorsqu’une nouvelle faille est découverte, il suffit donc de mettre à jour cet écran pour parer toute attaque via ladite faille ; ça laisse le temps de mettre à jour les scripts SPIP à tête reposée au moment idoine.

Téléchargement

Télécharger l’écran de sécurité :
https://git.spip.net/spip-contrib-o...

Le code de cet écran est consultable à l’adresse suivante :
https://git.spip.net/spip-contrib-o...

On peut aussi le récupérer et le synchroniser avec GIT :
git clone https://git.spip.net/spip-contrib-outils/securite.git

Le fichier est nommé ecran_securite.php

Installation

Il y a plusieurs méthodes pour installer cet écran :

Au niveau d’un site SPIP donné :

Il suffit de déposer le fichier ecran_securite.php dans le répertoire config/ du site pour qu’il soit pris en compte automatiquement.

Au niveau du serveur :

Déposer ce fichier dans un répertoire lisible par tous les sites (par exemple /usr/share/php/ecran_securite/).

Modifier php.ini, en ajoutant les lignes suivantes :

auto_prepend_file '/usr/share/php/ecran_securite/ecran_securite.php'

ou bien, modifier httpd.conf, en ajoutant :

php_admin_value auto_prepend_file '/usr/share/php/ecran_securite/ecran_securite.php'

Dans ces deux cas, l’écran est inclus à chaque « hit » php avant le lancement du script normal. Il peut donc bloquer tout appel « malfaisant ».

Configuration

Outre la sécurité, l’écran a la capacité de moduler les accès des robots d’indexation aux scripts php, de manière à leur dire de « revenir plus tard » lorsque le serveur est saturé.

Pour les versions récentes, ce comportement est configurable, en indiquant dans le fichier config/ecran_securite_options.php :

<?php
define('_ECRAN_SECURITE_LOAD', X);

Lorsque la valeur X n’est pas 0, ce réglage active la protection anti-robots quand la charge du serveur (load) excède la valeur.

Note :
Le mécanisme d’allègement de l’écran de sécurité s’active progressivement au fur et à mesure que le load dépasse la valeur seuil : à 4.01 de load il n’y aura quasiment aucune page renvoyée en erreur 429.

Il ne faut pas confondre un load de 4 et une charge CPU de 400% : il n’y a pas de correspondance directe.
-  le load reflète les processus en attente, ce qui n’est pas forcément dû à la CPU (parfois ce sont les I/O —notamment d’un NFS—. cf Load_average)
-  l’interprétation de la charge CPU dépend du type d’hébergement (mutualisé, VPS,...) et ne doit pas s’évaluer uniquement à l’aune du nombre de processeurs de la machine.

Fonctionnement de l’écran

L’écran intervient le moins possible, il ne fait que bloquer des variables dont on sait qu’elles ont été, à un moment donné de l’histoire de SPIP, mal contrôlées, et qu’elles pouvaient par conséquent donner lieu à une attaque. Il est donc compatible avec toutes les versions de SPIP.

Toutefois, l’écran verrouille systématiquement certaines variables. Ainsi, par exemple, les variables nommées id_xxx sont toutes contrôlées comme étant obligatoirement des valeurs numériques entières, afin d’éviter toute injection de code SQL via ce genre de variable très courante.

Par ailleurs il bloque l’accès, pour les robots seulement, aux pages comportant plusieurs paginations simultanément (car la combinatoire issue de plusieurs paginations peut entraîner un trop grand nombre de requêtes).

Vérification et test

Pour vérifier la bonne exécution du script, appeler le site public en ajoutant à l’url soit ?test_ecran_securite=1, soit &test_ecran_securite=1.

l’affichage résultant devrait être :

Error 403
You are not authorized to view this page (test 1.6.7)