Dominique Meeùs
Dernière modification le
retour à la table des matières
— à l’index
— à ma page de départ
Dans ce qui suit, je fais l’hypothèse que le serveur tourne sous Linux.
Sur un site en hébergement partagé, le maître du site, qui est aussi le client de l’hébergeur, est un utilisateur du serveur, disons sous le nom fooclient pour fixer les idées. Il peut placer par FTP ou autre (comme cPanel ou Plesk) des pages Web statiques (fichiers HTML) ou d’autres fichiers, dont il est alors le propriétaire.
En hébergement partagé, on utilise le plus souvent des applications PHP. L’utilisateur qui exécute ces applications n’est généralement pas l’utilisateur fooclient, mais le serveur Web installé sur la machine Linux. Ce serveur Web peut porter différents noms comme www-data, apache, parfois nobody. Supposons que c’est l’utilisateur apache pour fixer les idées. En général, fooclient n’est pas non plus dans le groupe d’apache et réciproquement.
Cela pose le problème de l’accès aux fichiers. Pour qu’apache puisse exécuter une application PHP installée par FTP par fooclient, il faut que les dossiers de l’application soient autorisés à tout le monde en lecture et en exécution et les fichiers en lecture. Si l’application doit créer des fichiers, le dossier correspondant doit être autorisé en écriture à tout le monde. Si l’application doit modifier des fichiers, ceux-ci doivent être autorisés en écriture à tout le monde. Réciproquement, si l’application elle-même a été installée par un script exécuté par apache, c’est alors ce dernier qui est propriétaire des dossiers et fichiers. À la limite, ces fichiers et dossiers peuvent être invisibles à fooclient, ce qui n’empêche pas l’application de fonctionner, mais qui peut être ressenti comme inquiétant : « où est passée mon application ? ». Si le maître du site doit cependant accéder à certains fichiers de l’application, comme pour les personnaliser (configuration, CSS…), apache devra de même donner accès à tout le monde en lecture et écriture à ces dossiers et fichiers.
Il faut évidemment relativiser les risques de l’accès « à tout le monde ». Il ne s’agit
jamais que du monde des utilisateurs du serveur. En hébergement partagé, des barrières
(comme open_basedir
) empêchent les différents clients d’accéder aux dossiers des autres. Si un intrus
arrive à se faire utilisateur du serveur, il a donc encore d’autres obstacles à vaincre
avant de pouvoir s’attaquer au site d’un client, à moins qu’il n’ait réussi à accéder
comme root. Le risque d’un utilisateur intrus malveillant du site n’est pas nul, mais le risque
le plus grand c’est celui d’un intrus par FTP qui aurait réussi à connaître le nom
et le mot de passe FTP de fooclient.
En lien avec cette problématique, il a le moyen de changer de propriétaire, de changer les permissions (de manière récursive) et de gérer les fichiers qui n’appartiennent pas au maitre du site : ce que j’ai trouvé le moyen de faire avec eXtplorer. Problème annexe, quel que soit le propriétaire, déployer sur le site des applications comprimées plutôt que d’y copier les fichiers un à un. C’est une chose qu’eXtplorer fait aussi.
Table of contents