Bloquer l'exécution de PHP dans modules/ avec .htaccess (PrestaShop 1.7 et 8)

L'une des améliorations de sécurité les moins commentées de PrestaShop 9 tient dans un fichier d'une douzaine de lignes : le .htaccess livré par défaut dans le dossier modules/. Avec lui, Apache répond 403 à toute requête directe vers un .php de module, avant même que PHP ne démarre.

Dans PrestaShop 1.7 et 8, ce fichier n'existe pas. N'importe quel .php présent dans modules/, qu'il appartienne à un module installé, à un module désinstallé ou à une porte dérobée, peut être appelé par URL et s'exécute. Cet article explique comment apporter cette protection à votre boutique sans rien casser.

Pourquoi c'est important

Presque tout ce que fait un module moderne passe par le dispatcher de PrestaShop : les contrôleurs front s'appellent sous la forme index.php?fc=module&module=nombre&controller=accion (ou leur URL simplifiée), et ceux d'administration passent par le back-office. Aucun de ces chemins n'a besoin d'appeler directement un .php de modules/.

Ce qui est appelé directement, en revanche :

• Des fichiers hérités de vieux modules : ajax.php, validation.php, des scripts de cron ou d'import qui démarrent PrestaShop par eux-mêmes. Certains ont des vulnérabilités connues.
• Des fichiers de modules orphelins, qui restent sur le disque même si le module a été désinstallé.
• Des portes dérobées laissées dans le dossier d'un module, souvent avec un nom qui paraît tout à fait banal.

Refuser les .php appelés directement ferme les trois d'un coup. Ce qui reste ouvert, c'est uniquement ce qui passe par le dispatcher, beaucoup plus facile à vérifier.

Ce que fait exactement PrestaShop 9

Le fichier par défaut utilise un FilesMatch qui refuse par extension, avec les directives d'Apache 2.2 et d'Apache 2.4. Il refuse .php et aussi d'autres fichiers qui ne devraient jamais être servis depuis cet endroit : .log, .txt, .lock, .json, .yml, .yaml, .tpl, .twig, le config.xml de chaque module et ses variantes par langue. Les CSS, JavaScript et images des modules continuent d'être servis normalement.

Comment l'appliquer dans PrestaShop 1.7 et 8

1. Dressez la liste de ce qui est appelé directement. Avant de fermer, parcourez les journaux d'accès du serveur des dernières semaines à la recherche de requêtes vers /modules/ qui se terminent par .php et répondent 200. C'est la liste de ce que vous pourriez casser.
2. Classez chacune. Retours de passerelles de paiement, crons programmés dans le panneau, appels Ajax d'un ancien module. Chacune est soit une exception justifiée, soit quelque chose qu'il vaut mieux remplacer.
3. Créez le fichier modules/.htaccess avec un refus des .php et des extensions de configuration, sur le modèle de celui de PrestaShop 9. Sous Apache 2.4, la règle essentielle est <FilesMatch "\.(php|phtml|phar|php[0-9])$"> Require all denied </FilesMatch>. Inclure phtml, phar et les variantes numérotées évite qu'un fichier portant une autre extension que le serveur exécute aussi ne passe entre les mailles.
4. Ajoutez les exceptions dans le dossier de chaque module, pas dans le dossier général. Par exemple, dans modules/mipasarela/.htaccess : <Files "notificacion.php"> Require all granted </Files>. Ainsi, l'exception ne vaut que pour ce fichier de ce module, et non pour tout fichier du même nom dans un autre dossier.
5. Vérifiez avec de vraies requêtes. Appelez un .php quelconque d'un module (il doit renvoyer 403), appelez celui de l'exception (il doit répondre) et passez une commande de test avec chaque moyen de paiement.
6. Vérifiez les crons. Si un cron du panneau appelait modules/x/cron.php, il échouera désormais sans prévenir. Remplacez-le par l'URL du contrôleur du module s'il en a une, ou laissez-le en exception.

Les limites à connaître

• Cela ne protège pas les contrôleurs front. Un controllers/front/ est servi via index.php, donc le .htaccess de modules/ ne le couvre pas. Si un module installé a un contrôleur vulnérable, il reste vulnérable. Il n'y a pas de raccourci : mettre à jour ou retirer le module.
• Nginx ignore les .htaccess. Si votre serveur est en Nginx pur, le refus se fait avec un bloc location dans la configuration du serveur, ce qui relève normalement de votre hébergeur.
• Cela suppose que le serveur lise les .htaccess (directive AllowOverride). Vérifiez-le en appelant un .php après avoir créé le fichier ; ne le tenez pas pour acquis.
• Un attaquant disposant d'un accès en écriture peut le supprimer. Si quelqu'un peut écrire dans modules/, il peut retirer le .htaccess. Sa disparition n'a aucune cause légitime, donc surveiller sa présence est en soi une alarme utile.

Les autres dossiers : upload/, img/, var/

upload/ et download/

C'est là que vont les fichiers envoyés par les clients pour les produits personnalisables et les produits téléchargeables. PrestaShop les sert via un contrôleur, pas par accès direct. Dans PrestaShop 9, download/ refuse tout et upload/ refuse les fichiers portant le nom interne que leur donne PrestaShop. Aucun des deux ne devrait jamais contenir de .php, donc y ajouter un refus de PHP est sans risque. Si, en plus, votre boutique ne sert rien de upload/ par URL directe, vous pouvez tout refuser, mais vérifiez-le avant.

img/

Dans PrestaShop 9, il refuse tout sauf les extensions d'image, de vidéo, de PDF et d'icônes. Dans les versions antérieures, regardez ce que contient votre img/.htaccess : il peut avoir ses propres règles, donc ajoutez le refus de PHP à la fin, sans remplacer ce qui existe. Et quand vous régénérez le .htaccess de la racine depuis le back-office, vérifiez ensuite que vos blocs sont toujours là où vous les avez laissés.

var/ et cache/

Depuis la 1.7, var/ comporte un refus total. Vérifiez que le fichier est toujours là : un var/logs accessible divulgue des chemins, des erreurs et parfois des données clients. Dans les boutiques 1.6, le dossier équivalent est cache/, et il ne doit pas servir de PHP.

La racine

Vérifiez aussi qu'aucune sauvegarde (.zip, .sql, .tar.gz) ni aucun journal d'erreurs de l'hébergement n'est accessible à la racine. Un dump de base de données téléchargeable est pire que n'importe quelle shell.

Comment le résoudre dans PrestaShop

RKR Security Alert dispose d'un panneau de durcissement des dossiers de données qui vérifie que le .htaccess de upload/, download/, img/ et d'autres dossiers non seulement existe, mais bloque réellement l'exécution, et vous alerte si quelque chose d'exécutable apparaît là où il ne devrait y avoir que des données. Il peut écrire le bloc de refus pour vous, en l'ajoutant à la fin du fichier existant et en conservant une copie. Pour modules/, il regarde quelles extensions le .htaccess refuse réellement et les croise avec les points d'entrée qu'il trouve, et chaque découverte du scanner indique si elle est accessible par URL ou fermée. Si vous préférez ne pas y toucher vous-même, avec un forfait d'heures de support Rekire nous examinons les journaux, définissons les exceptions nécessaires et testons le tout avec de vraies commandes.