Améliorer la sécurité de WikiNi avec un fichier .htaccess
Lorsque
WikiNi est installé, n'importe qui peut accéder à n'importe quel fichier dans l'arborescence du logiciel. Par exemple, rien n'empêche d'accéder au fichier include.php en tapant dans un navigateur
http://example.org/wikini/action/include.php. En situation normale, cela ne devrait pas avoir de conséquence puisque les fichiers de
WikiNi testent que l'accès au fichier est bien effectué par wakka.php.
Cependant, il existe des cas où ce comportement peut-être préjudiciable :
- si l'hébergeur désactive, ne serait-ce qu'une minute, l'interprétation du code PHP, alors le contenu du fichier de configuration devient lisible (mot-de-passe d'accès à la base de données, etc.) !
- dans le cas d'un fichier de WikiNi mal écrit, un utilisateur mal intentionné pourrait exécuter du code non souhaité avec certains privilèges
Si vous utilisez un serveur web Apache, l'utilisation d'un fichier .htaccess vous permet d'améliorer votre protection contre ces risques.
Mise en oeuvre
<Files wakka.config.php>
- Order allow,deny
- deny from all
</Files>
Archives des discussions
Est-ce que l'utilisation d'un .htaccess ne serait pas plus judicieuse ? --
CharlesNepote
Surement, mais j'ai peur que des utilisateurs novices se trouvent devant des erreurs incompréhensibles pour eux, si le comportement de .htacccess a été modifié par l'hebergeur (c'est d'ailleurs pour cela que j'avais supprimé le htacces url rewriting au tout début de wakkafr ...) --
DavidDelon
Le problème du .htaccess en dehors de sa complexité relative, c'est que ca ne marche
que sous Apache qui n'est pas le seul serveur web du marché (pas encore). Je pense donc que ce n'est pas la solution, mais l'administrateur du wiki peut très bien "en plus" protéger les répertoires avec un fichier .htaccess. --
GarfieldFr
Il me semble pourtant que la gestion des droits d'accès via .htaccess est gérée par 99.999% des hébergeurs (ce qui n'est pas le cas de la réécriture d'URL). Les installations de
WikiNi sous IIS doivent être assez rares et il me semble que les autres serveurs web gèrent les fichiers .htaccess.
Je vois deux solutions possibles pour améliorer la sécurité sous cet angle :
- documenter ici même un fichier .htaccess mais sans l'intégrer à la distribution de WikiNi
- tester à l'installation si l'hébergeur gère les .htaccess (je ne sais si cela est possible)
Soit dit en passant, on retombe sur le problèmes suivants : quels sont les pré-requis exacts pour faire fonctionner
WikiNi ? qu'est-ce qui est installé par défaut chez les hébergeurs ?
Je vais tâcher (mais vous pouvez m'aider ;) de compléter la
DocumentationAdministrateurTechnique.
--
CharlesNepote
Rien ne nous empèche de mettre une documentation sur la configuration des .htaccess et même de les fournirs avec la distibution. Mais le code php de sécurité peut très bien rester au cas ou le serveur ne gère pas les .htaccess, c'est ce que fait PHPNuke par exemple, ainsi que d'autre CMS. Comme cela, il y a .htaccess si l'on est sur un serveur Apache et le code php de sécurité si on est sur un autre serveur, pas besoin de pré-requis autre que sur PHP et
MySQL. Au passage, seulement 50% des serveur web dans le monde sont des serveurs Apaches d'après une étude parue il y a un an (Gardner Group je crois). Beaucoup de serveur IIS sont en entreprise et même dans le cadre d'un intranet, il faut veiller à ce que l'utilisateur ne fasse pas de bétise... --
GarfieldFr
Ok. Vous m'avez convaincu. --
CharlesNepote
Sur le fait de protéger via un
.htaccess, que se passerait-il dans le cas où on utiliserait pas Apache ou encore dans le cas où l'hébergeur n'autoriserait pas
Limit : le fichier
wakka.config.php serait accessible. Pire : si l'hébergeur désactivait, ne serait-ce qu'une minute, l'interprétation du code PHP (ça m'est arrivé lors d'une mise à jour foireuse), alors le contenu du fichier de configuration serait lisible ! Il faut donc effectivement préciser ces pré-requis pour
WikiNi. Ma solution pour le problème du PHP non interprété, c'est de mettre les mots de passe dans un fichier hors de l'arborescence web, mais accessible via un
include PHP ; je ne sais absolument pas si c'est faisable chez la plupart des hébergeurs, qui doivent probablement rendre le répertoire FTP entièrement accessible via la web, je suppose ...
--
ProgFou
- Personnellement, je suis contre la protection via .htaccess car elle n'est pas portable d'un serveur à l'autre. IIS par exemple ne supporte pas ces fichiers, il est vrai que IIS n'est pas le serveur le plus utilisé dans le monde, mais beaucoup d'entreprise l'utilise comme serveur web d'Intranet. A ma connaissance, seul Apache utilise ces fichiers pour la protections. Si l'on veux que WikiNi soit installable n'importe ou, il ne faut pas se reposer sur des fonctionnalités liés au serveur HTTP. --GarfieldFr
- On est d'accord ! -- ProgFou
- Oui, mais tu connais beaucoup de serveur IIS avec PHP ? Même sous Windows la tendance est plutôt à installer PHP sur Apache depuis que Apache 2.0 supporte bien Windows. Mais je suis d'accord sur le fait qu'il faut faire les deux (.htaccess et code PHP). -- 2004-02-17 OlivierMengu?é.
- J'en connais au moins un : mon hébergeur est sous IIS. De plus, je pense que dans les entreprises, dans le cadre d'un intranet, les serveurs IIS sont surement plus présent que Apache. Mais de toutes façon, utiliser .htaccess, c'est rejeter la sécurite sur un programme externe ce qui n'est pas à mon avis souhaitable. --GarfieldFr