Explication de .htaccess

Une configuration qui vit dans le dossier

Un serveur web a un fichier de configuration principal que seul son administrateur peut modifier. Sur un hébergement mutualisé, ce n’est pas vous : Apache vous offre donc une autre porte d’entrée. C’est un fichier texte brut nommé .htaccess, placé dans un dossier du site, dont les instructions s’appliquent à ce dossier et à tout ce qu’il contient. Les serveurs LiteSpeed lisent le même fichier. nginx ne le lit pas et l’ignore complètement.

Le serveur relit le fichier à chaque requête : un changement prend donc effet dès que vous enregistrez. Une erreur aussi. Une seule directive mal orthographiée et toutes les pages répondent par une erreur 500 jusqu’à ce que vous corrigiez la ligne. Gardez une copie avant chaque modification.

Vous êtes rarement le seul auteur. WordPress écrit un bloc entre # BEGIN WordPress et # END WordPress et les extensions de cache, de sécurité et d’images ajoutent leurs propres blocs balisés. L’explication reconnaît les marqueurs d’environ 25 d’entre elles, dont WP Rocket, LiteSpeed Cache, Wordfence et Really Simple SSL et nomme le propriétaire de chaque bloc.

Lire une règle de réécriture à voix haute

mod_rewrite est l’endroit où la plupart des gens se perdent. Prenons cette paire :

RewriteCond %{HTTP_HOST} ^shop\.example\.com$ [NC]
RewriteRule ^products/(\d+)$ https://www.example.com/item?id=$1 [R=301,L]

Elle se lit comme une phrase : « Si l’hôte demandé est shop.example.com, quelle que soit la casse et que le chemin est products/ suivi de chiffres, envoyer le visiteur de façon permanente vers la nouvelle adresse avec ces chiffres comme id et arrêter le traitement. »

• Une RewriteCond est une condition sur une variable du serveur. Elle ne s’applique qu’à la RewriteRule suivante. Plusieurs à la suite doivent toutes être vraies, sauf si l’une se termine par [OR].
• La première partie d’une RewriteRule est une expression régulière testée sur le chemin. Les parenthèses capturent du texte et $1, $2 le réutilisent dans la destination. %1 réutilise une capture de la dernière condition.

Ce qui est signalé

Les attaquants qui obtiennent un accès en écriture à un site visent souvent .htaccess, parce que quelques lignes suffisent pour rediriger les visiteurs ou garder un script caché accessible. L’explication compare chaque ligne à des schémas observés dans de vraies infections et lui donne l’une de deux étiquettes.

Suspect, affiché en rouge :

• une redirection vers un autre domaine qui ne s’applique qu’aux visiteurs venant d’un moteur de recherche, ou seulement aux téléphones. Le propriétaire, qui tape l’adresse directement sur un ordinateur, ne la voit jamais ;
• un script PHP différent servi aux robots d’exploration des moteurs de recherche ;
• AddHandler, AddType ou SetHandler qui font exécuter des fichiers image ou texte comme du PHP, ou des fichiers ordinaires comme des scripts CGI ;
• php_value auto_prepend_file ou auto_append_file qui charge un fichier avant ou après chaque script et allow_url_include ;
• un bloc FilesMatch qui interdit tous les fichiers .php, .py et .exe, suivi d’un bloc qui autorise une courte liste de fichiers PHP que WordPress ne fournit pas.

À vérifier, affiché en orange : les lignes dans le bloc WordPress qui ne font pas partie de ses règles standard, les conditions visant seulement les robots ou les référents, le drapeau [P], une page d’erreur hébergée sur un autre domaine, l’affichage du contenu des répertoires activé, des erreurs PHP affichées aux visiteurs, un pare-feu applicatif désactivé, des lignes de plus de 400 caractères ou remplies de base64 ou de caractères encodés et des caractères invisibles.

Deux erreurs de structure sont aussi signalées, puisque les deux provoquent un 500 : un bloc comme <IfModule> qui n’est jamais fermé et des directives qui ne sont permises que dans la configuration principale du serveur, comme DocumentRoot ou <VirtualHost>.

Si une ligne est signalée et que ce n’est pas vous qui l’avez écrite

1. Téléchargez une copie du fichier comme preuve avant de toucher à quoi que ce soit.
2. Vérifiez la date de modification du fichier et cherchez d’autres fichiers modifiés au même moment, surtout des fichiers PHP dans les dossiers de téléversement et les noms cités dans les règles signalées.
3. Supprimez les lignes hostiles, puis rechargez le fichier quelques minutes plus tard. Si elles sont revenues, un script sur le serveur le réécrit et supprimer des lignes ne suffira pas.
4. Changez les mots de passe de l’hébergement, du FTP ou du SSH, de la base de données et de l’administrateur du CMS, puis mettez à jour le CMS avec toutes ses extensions et tous ses thèmes.
5. Lancez la recherche de site dangereux pour voir si le site figure déjà sur une liste de blocage de navigateur et le suivi de redirections pour confirmer que les visiteurs arrivent là où ils le devraient.