- Publié le 26 Août 2008 à 23:34
Clochix a publié cette semaine deux articles à propos de sécurité; le premier sur les CMS en général et le second plus spécifiquement sur eZ Publish. Le problème pointé est l'affichage par défaut de tous les objets dans eZ Publish par les templates par défaut même lorsque cela ne devrait pas arriver. La solution (simple) proposée est de faire des surcharges s'appliquant en dernier et n'affichant rien pour éviter d'afficher tout ce qui n'a pas été prévu. Évidemment il est toujours mieux de restreindre les droits, mais c'est un bon dernier rempart à la divulgation d'informations...
Il y a évidemment d'autres éléments à considérer et j'en oublie probablement d'ailleurs mais voici ceux qui me viennent à l'esprit.
Au niveau template, il faut toujours penser à utiliser l'opérateur wash(), il permet de s'assurer que tous les caractères spéciaux sont échappés pour produire du code XHTML valide mais aussi pour éviter des attaques de type XSS si surtout votre site propose aux internautes de contribuer.
Au niveau système pour un site en production, seul le répertoire var devrait permettre l'écriture au serveur web. On peut aussi restreindre les droits de l'utilisateur MySQL utilisé par eZ Publish pour limiter la portée d'une éventuelle mauvaise utilisation de ce compte.
On peut aussi penser à désactiver les modules et/ou les vues inutiles pour un siteaccess donné. Par exemple, pour ce site, le fichier site.ini.append.php de mon siteaccess correspondant au front comporte la configuration suivante :
[SiteAccessRules]
Rules[]
Rules[]=access;enable
Rules[]=moduleall
Rules[]=access;disable
Rules[]=module;user/register
Rules[]=module;user/forgotpassword
Rules[]=module;user/activate
Rules[]=module;user/success
Rules[]=module;ezinfo
Ces quelques lignes désactivent quelques vues du module user ainsi que le module ezinfo qui sont accessibles aux utilisateurs anonymes alors qu'ils ne me sont pas nécessaires. La vue ezinfo/about en particulier donne des informations sur les extensions activées et surtout sur la version d'eZ Publish ce qui permet de savoir à quoi est potentiellement vulnérable le site. Dans tous les cas, il vaut mieux être à jour, les versions 4.0.0, 3.10.0 et 3.9.4 sont vulnérables à quelques failles connues.
Il faut aussi penser à nommer les fichiers de configuration en .ini.append.php et à encadrer le contenu par des commentaires PHP ce qui évite toute possibilité de lecture via un accès direct par le serveur web. À ce niveau, avoir un site eZ Publish en mode Virtual Host devrait aussi apporter un gain en cachant presque complètement l'arborescence "physique" du site.
Enfin au niveau des extensions il faut évidemment penser à échapper toutes les données inconnues avant de l'utiliser dans une requête SQL (ça n'est pas spécifique à eZ Publish !), la méthode escapeString() de la classe eZDBInterface est faite pour ça.
- Publié le 18 Août 2008 à 00:24
Notes aux grincheux de service : la manipulation exposée dans ce billet fonctionne évidemment ailleurs que sous Ubuntu (en fait partout où Apache2 est installable), néanmoins elle a été testée et mise en place sous Ubuntu et fonctionne telle quelle avec l'installation d'Apache2 par défaut sur cette distribution.
Après avoir appliqué la règle 3 en ajoutant et configurant l'entête Expires, passons à la règle 4 du Livre High Performances Web Sites (ou des recommandations de performances Yahoo!) en compressant avec gzip les données transmises par le serveur web, ici Apache2. Comme son nom le suggère, cette règle vise à limiter au maximum le poids des contenus distribués en réduisant de près de 70% la taille des fichiers textes. Cela permet d'accélérer le premier chargement du site avant la mise en cache par le navigateur. Pour cela, on peut configurer Apache2 pour utiliser le mod_deflate qui va se charger de compresser ce qui peut l'être pour un sur coût CPU faible.
La première étape consiste à activer ce module ainsi que le module headers avec a2enmod et à recharger Apache pour prendre en compte ce nouveau module :
$ sudo a2enmod deflate
$ sudo a2enmod headers
$ sudo /etc/init.d/apache2 reload
Le module headers est nécessaire pour envoyer des entêtes spécifiques aux proxy caches de manière à ne pas envoyer de documents compressés à certains navigateurs buggés mais populaires...
La configuration par défaut, stockée dans le fichier /etc/apache2/mods-available/deflate.conf, fait en sorte de compresser les fichiers texte brut, HTML et XML ce qui est déjà bien, mais on peut aller plus loin en traitant tout ce qui est texte. Il est en effet inutile de compresser les images (JPG, PNG, GIF, ...), les PDF et bien d'autres types de fichier qui sont déjà compressés par nature. J'utilise la configuration suivante dans /etc/apache2/conf.d/deflate pour compresser en plus les feuilles de style et les scripts Javascript tout évitant certains bugs connus de quelques navigateurs.
AddOutputFilterByType DEFLATE text/plain text/css application/x-javascript text/xml text/html
# gestion des navigateurs buggés
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4\.0[678] no-gzip
BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
# gestion des proxy caches
Header append Vary User-Agent
Pour faire prendre en compte cette configuration, il ne reste plus qu'à recharger Apache et le tour est joué.
- Publié le 12 Août 2008 à 21:55
Pascal Specht asks a good question in the eZ Publish forums : how to put a site under maintenance without breaking bookmarks and external links ?
The easiest way (the only ?) is probably to use mod_rewrite of Apache to distribute a maintenance page instead of the normal page. This can be done with those few lines in a .htaccess file :
RewriteEngine on
# RewriteCond %{REMOTE_ADDR} !^82.225.188.34$
RewriteRule (.*) /path/to/your/maintenance/file/index.htm [L]With this setting, Apache distributes the index.htm file for all request. You can also put your own IP address on the second line and uncomment it so that you can view the normal site for example to generate some caches in eZ Publish before putting your site online again.
- Publié le 11 Août 2008 à 23:49
Lire un livre sur comment optimiser son site web c'est bien, appliquer les conseils qui s'y trouvent c'est encore mieux. Parmi les 14 bonnes pratiques, 3 peuvent être appliquées très rapidement au niveau système en quelques lignes de commande et de configuration du serveur web pour un résultat quasi immédiat :
Dans un premier temps, je vais m'intéresser à la règle 3, je suppose que vous avez déjà un serveur web Apache2 actif servant des fichiers (peu importe la technologie autour). La configuration suivante est utilisée sur ma Dedibox sous Ubuntu avec Apache2 mais doit pouvoir s'appliquer à peu près partout.
Ajoutez et configurez l'en-tête Expires
L'en-tête Expires indique quand un élément devra expirer du cache du navigateur; mettre une date d'expiration dans un futur lointain permet de maximiser l'utilisation du cache navigateur et donc d'éviter les téléchargements inutiles, ce qui est particulièrement utile pour les éléments statiques (images, feuilles de style, ...) qui ont tendances à changer ... peu fréquemment mais à ralentir l'affichage de la page si ils ne sont pas en cache. Pour ces éléments, il est possible de configurer l'expiration dans Apache avec le module expires. Pour les pages dynamiques ou éléments générés dynamiquement, c'est au script d'envoyer l'en-tête et sa valeur adéquate par exemple avec la fonction header() en PHP.
L'activation du module pour Apache2, il faut utiliser a2enmod avec la ligne suivante et ensuite recharger apache :
$ sudo a2enmod expires
$ sudo /etc/init.d/apache2 reload
Il reste alors à configurer ce module. Je stocke la configuration de ce module dans le fichier /etc/apache2/conf.d/expires dont voici le détail :
ExpiresActive On
ExpiresByType image/gif "access plus 30 days"
ExpiresByType image/jpg "access plus 30 days"
ExpiresByType image/jpeg "access plus 30 days"
ExpiresByType image/png "access plus 30 days"
ExpiresByType image/x-icon "access plus 30 days"
ExpiresByType text/css "access plus 30 days"
ExpiresByType application/x-javascript "access plus 30 days"
Tous les éléments statiques des types listés expirent 30 jours après leur premier téléchargement. Après un nouveau reload d'Apache, vous devriez voir apparaître l'en-tête Expires par exemple avec l'extension Firebug de Firefox au premier chargement des éléments de la page. Ensuite le navigateur utilisera son cache ce qui devrait accélérer l'affichage des pages suivantes utilisant les mêmes éléments.
- Publié le 02 Décembre 2007 à 19:36
After 2 alphas and one beta release, eZ Publish 4 rc1 has been released last week. I'm trying to upgrade but I'm facing an encoding problem. In the meantime, I made a benchmark between eZ Publish 4rc1 with PHP 5.2.5 and eZ Publish 3.10.0 with PHP 4.4.7 on a Debian Etch system using the Dotdeb packages. I also tested the performances of APC, eAccelerator and XCache opcode cache modules in those configurations.
Protocol
I'm using the recommended configuration for Virtual Host setup of eZ Publish. I wrote this shell script to test performances of eZ Publish.
#! /bin/sh
REQUESTS=100
CONCURRENCY=2
TESTS=5
PAUSE_TESTS=90
URL='http://dev.pwet.fr/blog'
DATA_LOG_DIR=~/tests/results_php4_blog/
CONF_DIR=~/tests/conf
PAUSE_CONF=180
PHP_CONFD=/etc/php4/apache/conf.d/
[ ! -d $DATA_LOG_DIR ] && mkdir -p $DATA_LOG_DIR
for ini in $CONF_DIR/* ; do
INI_BASE=`basename $ini`
echo $INI_BASE
DATA_LOG="$DATA_LOG_DIR/$INI_BASE.dat"
[ -f $DATA_LOG ] && rm -f $DATA_LOG
touch $DATA_LOG
# active extension
ln -s $ini $PHP_CONFD/$INI_BASE
/etc/init.d/apache restart > /dev/null 2>&1
sleep 2
# initialize cache
wget $URL -O /dev/null > /dev/null 2>&1
sleep 2
# tests
for i in `seq 1 $TESTS` ; do
echo " Test $i"
ab -c $CONCURRENCY -n $REQUESTS $URL | grep 'Requests per' | tr -s ' ' | cut -d ' ' -f 4 >> $DATA_LOG
sleep $PAUSE_TESTS
done
sleep $PAUSE_CONF
rm -f $PHP_CONFD/$INI_BASE
/etc/init.d/apache restart
done I've run this shell script with a PHP4 setup (eZ Publish 3.10) and then with a PHP5 setup (eZ Publish 4.0rc1) sharing the same database. The script uses 4 configurations of PHP (no opcode cache, apc, eaccelerator, xcache), for each it makes 5 series of 100 requests with a concurrency of 2 with ab (Apache Benchmark) and it logs the mean number of requests per second. There are pauses between tests. I've run those tests on two pages of this site on a dedicated test server, the first one is the /blog page with view cache et cache-block enabled and the second one is /man/linux but with no view cache and no cache-block at all in order to see how eZ Publish 4 and 3.10 performs on retrieving its cache or on building a page from scratch. The first one makes 6 SQL queries and uses 2 cache-block and its view cache. The second one, without content related caches, makes about 100 SQL queries an displays about 10 XML blocks and 3 dynamic lists.
Result with a cached page
Without an opcode cache on cached page, eZ Publish 4 is about 10% quicker than eZ Publish 3.10 but with an opcode cache system, the difference is about 50% ! It's interesting to note that with PHP4, eAccelerator seems to be the faster yet, about 10% more than APC or XCache but with PHP5 there's almost no difference (more or less 2%).
Result with a page without content related cache
In this test, without an opcode cache, eZ Publish 4 is 85% faster than eZ Publish 3.10. And with an opcode, eZ Publish 4 using PHP 5.2.5 is about 150% faster than eZ Publish 3.10 !
Conclusion
No doubt, eZ Publish 4 is really faster than eZ Publish 3.10 and even more with an opcode cache.
I think I'm going to test eZ Publish 4 and 3.10 with apache 1.3 and apache 2.2 and perhaps with different configuration of MySQL 5.0, stay tuned :)
