Philosophy
When someone discovers and reports a “security hole” in SPIP, the SPIP development team tries to correct the problem as quickly as possible. Updates are made available for both the development and stable versions to help prevent the propagation of insecure code.
However, many users do not have the time or the ability to apply the updates, and they tend to weigh the risks of running potentially insecure code, with the chance that an upgrade might be incompatible with some of their existing code.
Information concerning a security issue is also something of a double edged sword for hosting providers: on one hand they do not wish to leave “security holes” on one of their hosted sites, but on the other they do not always have the authority to modify their clients’ sites. Taking a site offline is often not possible, except for cheap or paranoid hosting companies.
The security screen exists to answer these problems. It is a single file of PHP code completely independent from SPIP, which can be updated independently of the rest of the code, and which is compatible with all the versions of SPIP, even the oldest.
This file is not a substitute for upgrading your version of SPIP, but it can block certain attacks while waiting for a new, fixed, version of SPIP to be released.
In fact, the security screen can be activated on a whole web server and every PHP script it executes (SPIP or not), and guarantees, if it is up to date, that all the known security holes in every version of SPIP are impossible to exploit. This is the reason it is called a “screen”: it is placed between the visitor and SPIP, and checks that the visitor is not trying to exploit a known attack.
When a new fault is discovered, it is sufficient to update the security screen to avoid any attack via the aforementioned fault; this gives the site’s owner time to update SPIP to the latest version at their leisure.
Downloading
The most recent version of this screen is always available at: https://git.spip.net/spip-contrib-o...
The code for this screen is viewable at: https://git.spip.net/spip-contrib-o...
You can also download and synchronise it using GIT:
git clone https://git.spip.net/spip-contrib-outils/securite.git
The file is named ecran_securite.php
Installation
There are several methods to install the security screen:
For a single SPIP site:
It is enough to place the ecran_securite.php file in the config/ directory for the site and it will be loaded automatically.
For all sites on a server:
Upload the ecran_securite.php file to a directory accessible by all sites (for example: /usr/share/php/ecran_securite/).
Modify php.ini and add the following line:
auto_prepend_file '/usr/share/php/ecran_securite/ecran_securite.php'
or, modify your Apache configuration (httpd.conf or similar) and add:
php_admin_value auto_prepend_file '/usr/share/php/ecran_securite/ecran_securite.php'
Which ever you choose to use, the security screen is automatically included for every “hit” before PHP loads the script as usual. This allows it to block any “malicious” calls.
Configuration
In addition to security, the screen can also moderate traffic due to search engine robots, telling them “to return later” when the server is saturated.
For recent versions, this behaviour is configurable, by indicating in the ecran_securite_options.php file:
<?php
define('_ECRAN_SECURITE_LOAD', X);
This activates the “anti-robots” protection when the server load exceeds the value “X”. The default value is 4; to deactivate, put 0.
Note : Do not confuse a load of 4 with a CPU load of 400%: there is no direct correspondence. In particular the load reflects the waiting processes, which is not necessarily due to the CPU (sometimes it is the I/O -especially of an NFS-. cf Load_average)
The value of
_ECRAN_SECURITE_LOADshould not be evaluated exclusively in terms of the number of processors in the machine. Especially since the security screen lightening mechanism is activated progressively as the load exceeds the threshold value: at 4.01 load there will be almost no 503 sent.4 is a good value: it keeps the server performance satisfying; it avoids making the visitor wait.
Operation of the screen
The screen intervenes as little as possible; it only blocks variables that we know were, at some point in the history of SPIP, poorly controlled and that could therefore give rise to an attack. It is therefore compatible with all versions of SPIP.
However, the screen systematically locks certain variables. So, for example, variables named id_xxx are all checked as being mandatory integer values, in order to avoid any SQL code injection via this very common type of variable.
It also blocks access, for robots only, to pages with several paginations at the same time (because the combinatorial effect of several paginations can lead to too many requests).
Verification and testing
To check the correct execution of the script, call the public site by adding to the url either ?test_ecran_securite=1, or &test_ecran_securite=1.
the resulting display should be:
Error 403 You are not authorized to view this page (test 1.6.3)