Wikini

DocumentationSecuriserWikiNiAvecUnHtaccess

PagePrincipale :: DerniersChangements :: DerniersCommentaires :: ParametresUtilisateur :: Vous êtes ec2-54-92-236-20.compute-1.amazonaws.com

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 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>
</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 :
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





Il n'y a pas de commentaire sur cette page. [Afficher commentaires/formulaire]