- 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 14 février 2008 à 00:27
Plusieurs bugs de sécurté importants ont été découverts dans le noyau Linux, en particulier le bug CVE-2008-0600 permet à un utilisateur local d'obtenir un shell avec les droits root assez simplement. Même sans utilisateurs locaux, la faille peut devenir exploitable via une autre faille d'une application web par exemple, même si ça devient beaucoup plus compliqué.
La seule solution est de mettre à jour son noyau. J'ai réalisé cette opération tout à l'heure sauf que je ne connaissais pas encore le petit détail mentionné dans ce billet et rappelé dans un topic du forum Ubuntu-fr ce qui m'a donné un bon gros coup de stress :-) et une bonne heure de pwet.fr HS :-/
Bref, sur les dedibox utilisant le noyau fournit par Dedibox la manipulation est simple. Une fois le kernel spécifique installé, il faut indiquer l'emplacement de la racine du système avec l'ancienne syntaxe (type /dev/sdXY) au lieu des UUID. Sinon la machine ne reboote pas. Heureusement, les dedibox ont un système de rescue bien pratique qui permet de se sortir de ce genre de situation. Concrètement, avant pour chaque choix dans le fichier /boot/grub/menu.lst, j'avais quelque chose comme :
title Ubuntu, kernel 2.6.24.2
root (hd0,0)
kernel /vmlinuz-2.6.24.2 root=UUID=238ddcbc-cb7e-4023-a48e-932d874b5ef0 ro quiet splash
quiet
savedefault
que j'ai remplacé par
title Ubuntu, kernel 2.6.24.2
root (hd0,0)
kernel /vmlinuz-2.6.24.2 root=/dev/sda3 ro quiet splash
quiet
savedefault
Évidemment, /dev/sdaY est spécifique à l'organisation de la machine, il s'agit du numéro de la partition root du système. Il semble qu'avec le partitionnement par défault, il s'agisse de /dev/sda2. Avec le système de rescue de Dedibox, pour déterminer qu'elle est le bon numéro, il faut monter toutes les partitions du système et trouver le numéro de celle qui contient toute l'arborescence ( /bin, /usr, /lib, ...).
- Publié le 20 novembre 2007 à 00:21
Encore une belle Microsofterie qui n'est certes pas toute neuve mais qui commence à avoir des effets (pervers) puisque les concepteurs d'Outlook 2007 se sont dit qu'il serait bien d'utiliser le moteur de Word pour rendre les mails HTML à la place du moteur d'Internet Explorer pour, paraît il, améliorer la sécurité de leur logiciel malgré les tares de ce pauvre traitement de texte dans le domaine du rendu HTML et CSS...
Mais au moins, avant aujourd'hui, j'étais ignorant, je croyais que le navigateur le plus sécurisé produit par Microsoft ces derniers temps était Internet Explorer 7, mais maintenant je sais et vous pouvez tous le répéter autour de vous : " Le navigateur le plus sécurisé produit par Microsoft est ... Word 2007" :-) Y'a du boulot
- Publié le 06 octobre 2007 à 00:42
eZ Publish 4 Alpha 1
eZ Publish 4 arrive enfin, une première version alpha est sortie jeudi dernier basée sur le portage communautaire débuté par Kristof Coomans et Paul Borgermans. En terme fonctionnel ce ne sera probablement pas une révolution mais le principal atout de cette version est évidemment le support tant attendu de PHP5 (les utilisateurs de distribution Linux ne supportant que PHP5 vont apprécier). En plus de cela, je retiens deux points qui apportent des perspectives intéressantes :
- l'intégration progressive des eZ Components
- l'utilisation du mécanisme d'autoload de PHP5
L'intégration des eZ Components permettra dans un premier temps d'utiliser ces composants dans les extensions en attendant qu'ils soient réellement intégrer dans eZ Publish en lui-même. Cela ouvre déjà pas mal de perspectives intéressantes, en tout cas j'ai plein d'idées :-)
Le second point paraît plus anodin mais en fait, en plus de simplifier la vie du développeur, il pourra permettre de modifier facilement une classe du kernel eZ Publish sans vraiment le modifier. Ce n'est bien sûr pas recommandé mais c'est malheureusement parfois nécessaire et là on pourra le faire de manière presque propre.
LLaumgui parle aussi de cette sortie avec un commentaire instructif de Paul Borgermans.
Et le reste ?
À côté de cet évènement eZ Publish 3.10 est sorti avec des nouveautés fonctionnelles intéressantes (qui sont aussi de fait dans eZ Publish 4), en particulier :
J'ai testé les nouvelles fonctionnalités autour des URL en développant eZVideoFLV avec la 3.10beta ; habitué des _ et de l'ASCII c'est assez déroutant mais c'est enfin configurable et extensible, ça ne peut être que mieux. Je n'ai pas encore testé le datatype Multi-options2 mais ça ne saurait tarder.
Les versions 3.9.4 et 3.8.10 sont également sorties corrigeant deux failles de sécurité. Bref quoi qu'il arrive, des mises à jours sont à prévoir. Pour moi ce sera probablement en 3.10.x voire en 4.0 si une beta pointe le bout de son nez dans pas trop longtemps.
Enfin Clever Age publie sur son blog un article plutôt pertinent sur le support un peu délaissé des SGBD autres que MySQL par eZ Publish (qu'ils ne savent par contre pas orthographier correctement :p).
