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.
The most recent version of this screen is always available at:
The code for this screen is viewable at: http://zone.spip.org/trac/spip-zone/browser/_core_/securite/
You can also download and synchronise it using SVN:
svn co svn://zone.spip.org/spip-zone/_core_/securite/
The file is named
There are several methods to install the security screen:
For a single SPIP site:
Beginning with SPIP 2.0.9, it is enough to place the
ecran_securite.php file in the
config/ directory for the site and it will be loaded automatically.
For previous version of SPIP, you will also need to add the following code to
config/mes_options.php (create it if necessary):
The security screen will be loaded just after the
For all sites on a server:
ecran_securite.php file to a directory accessible by all sites (for example:
php.ini and add the following line:
or, modify your Apache configuration (
httpd.conf or similar) and add:
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.
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.
This behaviour can be configured at the top of the file, by including a line like:
This activates the “anti-robots” protection when the server load exceeds the value “X”. The default value is 4; to deactivate, put 0.
The next version of SPIP (version 2.1) will integrate the security screen; if a hole is discovered, the minimal fix will be to download the new
ecran_securite.php, and to upload it in the place of the old copy.
The security screen interferes as little as possible: it does nothing but block variables which are known to have been poorly used or validated in past or current versions of SPIP, and which could be used to mount an attack. It is thus compatible with all the versions of SPIP.
However, the screen “locks” certain variables. For example, all variables named like
id_xxx are required to be integer values, in order to avoid any injection of SQL code via this kind of very current variable.
Some plugins are not compatible with all the rules of the screen. For example, some use
&id_x=new to create a new X object. To be compatible with SPIP 2.1, these plugins will need to be modified to comply with the rules of the security screen.