Sécuriser un site eZ Publish

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.

» Commentaires

- partageons, partageons... (#67074) par Clochix le 27 Août 2008 à 08:38
Merci Damien pour ces précisions. On va peut-être réussir à lancer un site pour mettre en commun ce genre d'astuces et de bonnes pratiques.
- eZpedia ! (#67075) par Damien le 27 Août 2008 à 09:48
c'est vrai que j'ai tendance à oublier, mais il y a ezpedia qui permet ce genre de chose, par exemple la page sur la sécurité en Français pourrait être améliorée : http://ezpedia.org/wiki/fr/ez/security_ez_publish_security
- Autres details (#67076) par gggeek le 28 Août 2008 à 01:55
Peut-etre pas trop connus:

- par défaut le user 'guest' à accès au module content/pdf via le système de permissions. Aussi à désactiver via SiteAccessRules si inutilisé

- de même pour content/search, content/advancedsearch en front, si on ne donne pas cette possibilité (on peut les désactiver p.e. seulement en siteaccess frontend).

- Il y a aussi pas mal d'autres vues du module content qu'on peut désactiver: comme elles utilisent les permissions de content/read, elles sont toutes dispo pour le user anonyme. content/copy, content/browse, etc... (voir liste dans kernel/content/module.php)

- et encore: layout/set

- éviter de mettre dans la config de Apache acceptpathinfo=on si on utilise une config vhost avec les rewrite rules basées sur l'extension du fichier demandé

- dans le post original: "commentaire html" -> "commentaire php" pour les fichiers ini.append.php

- se rappeler que sans régles de rewrite, les fichiers .ini et .ini.append seront visibles par tout internaute. Vérifier s'il y en a dans les extensions installées

- se rappeler que les fichiers binaires uploadés sont accessibles à tout le monde, si on arrive à en deviner l'addresse

- le truc basic: éviter d'afficher les erreurs php à l'écran, mais garder le log des erreurs php activé (dans php.ini)
- Merci gggeek (#67083) par Damien le 29 Août 2008 à 14:45
merci gggeek pour ces informations, j'ai corrigé ma coquille.
Pour deviner l'adresse des fichiers binaire, c'est quand même pas simple de déterminer un md5 qui est me semble t il sur le timestamp et le nom du fichier (ou quelque chose du genre) ? Sinon pour le dernier point, c'est valable pour toutes les applications PHP (et leur autres technos)
- Petite question (#67196) par Wascou le 26 Octobre 2008 à 16:32
Supposons que sur un site eZ je me trouve avec un online editor mais que je ne veuille pas que mes internautes non authentifiés accèdent à la vue content/browse.

J'utilise ce qui a été indiqué dans le post et en essayant d'accéder à la vue concernée, je constate que la règle est bien appliquée, je n'ai pas accès à la vue car elle a été désactivée.

Petit problème, dans Online Editor, on a effectivement un appel à content/browse pour aller sélectionner des contenus existants. La vue étant désactivée, la fonctionnalité devient donc inutile...

Une solution pour contrer cela ?
- Liste (#67768) par pma le 23 Avril 2009 à 11:52
Y'a t'il une liste de tous les modules ? Histoire de savoir s'il vaut mieux : tout désactiver et activer certains, et tout activer et désactiver certains. Je parle bien sûr du siteaccess de front-office.
- Pourquoi faire simple... (#68008) par Hypolite le 21 Octobre 2009 à 23:23
Quelquechose me chagrine dans l'utilisation des SiteAccessRules : elles supposent que les utilisateurs n'étaient pas supposés avoir accès à certains modules ?

Pourtant le module de droit est plutôt fait dans le sens inverse, à savoir ne donner accès à rien à moins qu'on l'ai dit.

Alors il y a certes un piège, qui est la directive de configuration [RoleSettings] PolicyOmitList dans le site.ini.

Mais là encore, il s'agit juste de redéfinir quels modules on ne veut pas avoir à gérer dans le panneau des droits. Personnellement, je laisse le tableau vide pour un contrôle maximum.

Finalement, je sais exactement à quels modules mes utilisateurs anonymes ont le droit d'accès, et je n'ai besoin d'utiliser les SiteAccessRules que pour que les gens ne s'inscrivent pas par le formulaire d'inscription de la partie admin (s'ils la trouvent par mégarde).

» Trackback

Aucun trackback

Les trackacks sont désactivés

Flux RSS des billets

Flux RSS des billets

Rechercher sur pwet.fr

À retenir

Derniers commentaires

Archives

Nuage de tags

Bioutifoul photos

Quelques liens

Licence d'utilisation

Contenu sous Licence Creative Commons By-Sa

Sauf mentions spécifiques, les billets et les photos publiés sur ce site sont placés sous la licence Creative Commons by-sa.

Pour toute utilisation dépassant le cadre de cette licence, merci de me contacter par e-mail.

Login