Et si on se penchait sur la sécurité de votre site Joomla! ? Vous l’aimez bien votre site, vous le trouvez beau ; vous y avez consacré tellement d'énergie. Vous êtes fier du résultat et nul doute que vous pouvez l'être. Votre site est beau et utile.  Vous l’avez mis sur le net pour en faire profiter le plus grand nombre. Permettez-moi de faire une comparaison : imaginons que votre site devienne votre maison. Quand vous n’êtes pas chez vous, laissez-vous la porte ouverte ? Vos baies vitrées sont-elles grandes ouvertes en votre absence ? Non, bien sûr. Et votre site internet ? Avez-vous songé à fermer les portes et les fenêtres afin d'éviter que des cambrioleurs n'y pénètrent ?

Voyons de plus près ce que sont ces portes et fenêtres

A priori, un site Joomla! ne contient que deux portes d’entrée, celle de devant, côté rue et celle côté jardin.

Côté rue, c’est le fichier index.php qui se trouve à la racine du site et est donc accessible au travers de l’URL http://votresite/index.php. Tout le monde connaît cette adresse puisqu’il suffit de taper http://votresite pour y accéder. Aucune clef n’est requise pour l’ouvrir. Votre site est public.

Côté jardin, c’est aussi un fichier index.php dont l’URL est http://votresite/administrator/index.php. Dans un monde idéal, vous devriez être le seul à connaître l’existence de cette porte. Malheureusement, les hackeurs savent en tester l’existence puisqu’il suffit d’accéder à l’URL http://votresite/administrator/index.php et voir si le serveur répond "Oui, il y a une porte, je vous la montre" (code HTTP 200) ou "Non, il n’y a rien" (code 403, 404 ou autre).

Avons-nous des fenêtres dans notre site Joomla! ? Malheureusement oui et en très grand nombre : ce sont tous les programmes que nous installons c'est à dire les composants, les modules, les plugins, les templates, les librairies... qui viennent toutes avec quantité de fichiers PHP.
En théorie, nous l’avons vu ci-dessus, aucun fichier PHP ne devrait jamais être exécutable depuis une URL à l’exception de nos deux index.php mais à dire vrai, vous n’en savez rien.

Qu’est-ce qui vous dit que vous n’avez pas installé un composant qui propose un fichier PHP exécutable au travers d’une URL telle que, par exemple, http://votresite/components/com_dummy/helpers/send.php où send.php serait un fichier légitime de com_dummy et qui permettrait d’envoyer un email au webmaster si un bug est détecté dans com_dummy. Vous n’en savez rien et parfois le développeur ne le sait pas lui-même lorsqu’il utilise des librairies de code prêt à l’emploi.
Il est juste impossible de faire un tel suivi de toutes vos extensions. Chaque script ainsi appelable serait, dans notre comparaison, une fenêtre de notre maison : il convient de la fermer.

Vous pourriez aussi avoir des fichiers PHP dans, par exemple, le dossier /media : un composant tout à fait légitime aurait prévu un fichier PHP pour générer une feuille de style dynamiquement, un PHP pour générer une miniature d’une image, etc. Tout cela de manière parfaitement légitime pour ces développeurs.
Le soucis : vous n’avez aucune vue sur ces fenêtres ! Vous ne sauriez même pas déterminer si ces scripts sont légitimes ou malsains. En effet, les pirates déposent ici et là des fichiers PHP dans des dossiers tels que /administrator/components/com_admin, /components/com_content, /libraries/cms, /media/com_content... c'est à dire le plus souvent dans des dossiers natifs de Joomla!. Les fichiers ajoutés ont des noms "passe-partout" comme "content.php", "article.php", "food.php"... tous inexistants lors d’une installation fraîche de Joomla!.

Sécurisons notre maison et installons deux gardes du corps : à l’entrée et à la sortie

Il existe plusieurs applications de type "pare-feu" (firewall en anglais). Elles visent à ajouter ici et là des protections, des restrictions d’exécution, des interdictions d’accès à des dossiers sensibles, etc.

La majorité des protections sont mises en place par l’ajout de fichiers nommés .htaccess dans des dossiers sensibles comme /media, /images, /stories ou encore /tmp. Les dossiers mentionnés ici ont toute une caractéristique commune : à priori, il ne faut jamais y autoriser l’exécution d’un script PHP. En d’autres mots : une URL telle que http://votresite/media/food.php ne devrait jamais pouvoir être accédée parce que food.php n’a aucune raison légitime de se trouver dans le dossier des médias.

Imaginons le scénario suivant : un hackeur a réussi à exploiter une faille d’un composant se trouvant sur votre site ; une vieille version que vous aviez installée et oubliée de mettre à jour ou que vous aviez mal paramétrée (ayant par exemple autorisée n’importe qui à uploader un fichier). Cette situation n’a rien d’exceptionnel puisque la majorité des sites web ne sont maintenus que pendant un court laps de temps. Le site vieillissant, il n’est pas à l’abri d’une telle déconvenue. Le constat : tôt ou tard, un pirate réussira à pénétrer votre site et déposer un fichier PHP malsain où bon lui semble.

Idéalement, il faudrait donc deux gardes du corps : l’un va analyser tout ce qui rentre sur votre site et qui veillera à interdire tout qui n’est pas attendu (exemple : upload de fichiers) et l’autre va interdire l’exécution de code PHP non désiré.

Garde du corps n° 1 : interdire les entrées non autorisées dans votre maison

Il s’agit de choisir les bons réglages pour votre site : veillez précautionneusement à parcourir tous les écrans des réglages de Joomla!, à bien maîtriser les permissions (ACLs)... et à parcourir les écrans de réglages des différents composants installés pour restreindre les droits selon vos souhaits. Ainsi, vous pourriez avoir un composant de gestion de téléchargement de fichiers ; peut-être n’est-il pas nécessaire d’autoriser quelqu’un à charger un fichier depuis le frontend. Si c’est le cas, interdisez le droit "d’upload" à quiconque.

Pour être totalement certain qu’aucun upload ne pourra être fait par quiconque (y compris vous), vous pourriez créer un fichier php.ini à la racine de votre site et y inclure cette ligne :

file_uploads=off

Si votre hébergeur prend en charge la "surcharge" du fichier php.ini, vous venez d’interdire l’upload : un pirate ne pourra plus installer, via le web, un code malsain sur votre site. C’est d’emblée une protection maximale... (mais fortement génante sur un site vivant).

Si votre hébergeur ne le gère pas, voici l’équivalent à mettre dans son fichier .htaccess :

<IfModule mod_php5.c>
php_flag file_uploads Off
</IfModule>

(Attention : les mises à jour de Joomla!, d’extensions... ne fonctionneront plus, il vous faudra, par exemple, remettre la valeur sur "on" ou temporairement renommer le fichier php.ini afin qu’il ne soit plus traité par le serveur).

Garde du corps n° 2 : contrôler les sorties

Et si le garde à l’entrée était défaillant ? Et si un pirate était parvenu à sauver sur notre serveur un fichier PHP qui contient un virus, un relai pour générer du spam, etc. ?

Ce scénario est plus que probable puisque l’attaque pourrait avoir été faite par FTP ou via un site non sécurisé hébergé sur le même serveur que vous et chez un hébergeur très peu regardant à l’isolation des sites (un site corrompu pourrait à son tour corrompre tous les sites étant sur le même serveur web).

Le second garde du corps doit donc présumer qu’il travaille seul et ne pas se soucier si les blocages ont été ou non mis en place.

Une technique essentielle est d’interdire l’exécution des fichiers PHP qui se trouveraient dans des dossiers où il n’est pas attendu qu’ils puissent être exécutés, comme nous l’avons vu plus haut. Sous Joomla!, il y a plusieurs dossiers de ce type dont /images, /logs, /media, /stories et /tmp. A aucun moment, c’est à dire jamais, une URL telle que http://votresite/tmp/dummy.php ne devrait être exécutée. Jamais... sauf exceptions que vous mettrez alors en place au cas par cas.

Les exceptions sont ces composants dont les développeurs n’ont pas été assez strict sur l’isolation des codes et la structure des dossiers de Joomla!.

Pour sécuriser votre site, repérez ces dossiers "PHP interdit" et placez-y un fichier .htaccess avec le contenu ci-dessous.

Pour les dossiers /logs et /tmp, la ligne ci-dessous pour interdire toutes les URLs vers http://votresite/logs ou http://votresite/tmp. En effet, ces dossiers sont réservés à des usages internes de Joomla!.

Deny from all

Pour les dossiers /images, /media et /stories :

AddHandler cgi-script .php .pl .py .jsp .asp .sh .cgi
Options -ExecCGI

Il s’agit ici de retirer le droit d’exécuter un fichier PHP. Une URL http://votresite/images/dummy.php ne permettra donc plus d’exécuter ce virus.

Notez que, dans le cas de ces dossiers, vous pourriez éventuellement rencontrer des problèmes d’exécution de certains composants. Il convient donc de tester en profondeur et de long en large votre site après avoir mis en place ces fichiers .htaccess.

Aller plus loin

• certains dossiers comme par exemple /components, /modules ou /plugins ne possèdent pas de fichier PHP dans le dossier racine. Vous n’aurez donc jamais un appel http://votresite/plugins/un-script.php. Vous pourriez donc parfaitement y placer un fichier .htaccess qui interdirait l’exécution de code PHP dans le dossier racine (/components par exemple) mais qui l’autoriserait dans un sous-dossier ;
• d’autres dossiers n’ont pas pour vocation d’être accessibles depuis une URL, par exemple, le dossier /libraries. Il s’agit ici de librairies de fichiers source qui seront inclus par Joomla! lors de l’exécution d’une fonction. Ici encore, vous n’aurez jamais une URL du type http://votresite/libraries/un-script.php. Vous pouvez là aussi interdire l’exécution d’un script PHP s’il est appelé depuis une URL.

Ces fichiers .htaccess correctement programmés et mis à bon escient dans les différents dossiers de Joomla! vous permettront de protéger votre site web efficacement puisque, peu importe si un virus a pu être déposé sur votre site, il ne pourra pas être exploité s’il a été placé dans un dossier protégé.

Gardez cependant toujours à l’esprit que la sécurité 100% n’existe pas (il suffit de sauver le virus dans un sous-dossier de /components/com_content par exemple pour qu’il puisse alors être exécuté dans l’état actuel de votre protection, comme vu ci-dessus).

Quelques autres conseils

• Ne mettez jamais vos backups dans des dossiers tels que /backups, /_backups... ou encore de sauver vos backups à la racine de votre site avec un nom tel que "backup.zip" (ou backup.tar, backup.tar.gz, backup.gz, etc.). Il y a en effet des scripts spécialement développés pour lancer des requêtes (GET ou HEAD) http://votresite/backup.zip au petit bonheur la chance ;
• Si vous deviez installer phpMyAdmin, ne le faites pas à la racine de votre site (exclu donc http://votresite/phpmyadmin (ou /phpMyAdmin ou /pma ou ...)) car ici aussi, j’ai constaté de telles connexions sur mes sites ;
• Supprimez les fichiers LICENSE.txt, README.txt et web.config.txt (si vous êtes sous Apache) se trouvant à la racine de votre site puisqu’ils sont accessibles depuis une URL et permettent de savoir que vous avez un site en Joomla! ;
• Supprimez le fichier joomla.xml que vous trouverez à la racine de votre site car il est 1. inutile et 2. accessible depuis une URL (http://votresite/joomla.xml). Il dévoile que vous avez un Joomla! et la version de celui-ci ;
• Instaurez un mot de passe Apache (lisez un des nombreux tutoriels sur les fichiers .htpasswd) pour sécuriser votre dossier /administrator. Si vous disposez d’une adresse IP fixe, utilisez un blocage par liste blanche : seules les adresses IP autorisées pourront accéder à votre administration. A défaut d'un mot de passe / restriction par IP, interdisez l'accès aux fichiers .ini, .sql, .sh, .txt ou encore .xml de votre administration (ceci afin de bloquer des URLS telles que http://votresite/administrator/components/com_admin/admin.xml) ;
• Pensez à mettre vos fichiers /index.php, /administrator/index.php et /templates/votretemplate/index.php en chmod 444 pour ne plus les rendre modifiables ;
• ...

Gardez à l’esprit que, comme pour d’autres matières (optimisation du site, référencement...), la sécurité est un processus permanent et ne présumez jamais que vos gardiens sont infaillibles. Faites des sauvegardes régulières, testez-les en local, faites vos mises à jour de manière régulière, analysez les fichiers logs de votre serveur Apache, surveillez les changements qui sont apportés sur les fichiers de votre site, soyez alerté lorsqu'un nouveau fichier est créé...

La sécurité de votre site est une partie de votre maintenance, on l’oublie trop souvent et on s'en souvient toujours trop tard.