.htaccess : redirections, handlers PHP et spam

Ce que .htaccess fait vraiment

C'est la config Apache *dans* le dossier : réécritures, accès, types de fichiers. WordPress s'en sert pour les permaliens. Le vider « pour que ça marche » casse les URL et n'enlève pas une copie du même fichier dans `/uploads` ou un sous-dossier oublié.

L'attaquant aime ça : pas besoin d'un gros PHP visible, une règle suffit à cloaker. Le propriétaire voit une home normale sur desktop. Voir aussi les redirections « site qui redirige » dans l'esprit des guides, ici le détail serveur.

On ne donne pas de recettes de règles malveillantes. On dit : toute ligne que vous n'avez pas posée (et qui n'est pas le bloc standard CMS) est suspecte. On l'isole, on ne la « corrige » pas au feeling.

Redirections conditionnelles

User-agent mobile, pays, referer Google, cookie d'admin absent : la règle n'atteint pas votre Firefox de bureau. D'où les clients qui « voient un casino » et vous, rien. Testez téléphone, navigation privée, lien issu de Google. Search Console inspection : le HTML vu par Googlebot.

Une RewriteRule vers un domaine tiers, ou vers un PHP interne, se copie *avant* retrait. C'est la preuve de cloaking, utile au réexamen et au constat si phishing.

Les redirections « métier » (www, HTTPS, boutique) existent. Comparez à une sauvegarde *connue* ou au bloc généré par le CMS. Le trop-plein de conditions est le signal, pas le simple `RewriteBase`.

• Tester comme un visiteur, pas comme un admin.
• Copier le fichier pirate entier.
• Remettre le bloc CMS officiel, puis *vos* règles métier une à une.

Handlers et exécution déguisée

Des directives de type de fichier / moteur (AddHandler, SetHandler, et équivalents) peuvent faire traiter comme PHP ce qui s'appelle `.jpg`, `.ico`, sans extension. Vous « nettoyez les .php » et l'upload reste une porte. D'où interdire PHP dans les uploads *et* la lecture du htaccess de ce dossier.

Vous n'avez pas à expérimenter quelle ligne exécute quoi. Vous avez à retirer ce qui n'est pas dans la doc de votre CMS / hébergeur, puis à vérifier qu'un média ne s'exécute plus (l'hébergeur peut confirmer le comportement attendu).

Un handler légitime rare existe sur des stacks particulières. En mutualisé WordPress standard : presque jamais. En cas de doute, ticket host plutôt qu'un forum « ajoutez cette ligne ».

Plusieurs fichiers, plusieurs niveaux

Racine, `/wordpress`, `/blog`, chaque dossier d'uploads, anciens sous-sites. Un nettoyage de la racine laisse `/wp-content/uploads/2021/.htaccess`. Inventaire : chercher le *nom* de fichier sur tout le compte, pas « le » htaccess.

Les backups de htaccess (`htaccess.bak`, `.old`) encore lus par erreur, ou repris par un script. Sortez-les du web.

Les fichiers `apache.conf` déposés, les `.user.ini` / `php.ini` locaux : même tournée. Une porte peut vivre là, pas dans htaccess.

Copier, comparer, extraire

Copie horodatée hors site. Diff avec le fichier généré par « permaliens > enregistrer » *après* site déjà propre, ou avec une archive saine. Extraire *vos* règles (HTTPS, www) sur papier, les réappliquer sur un fichier neuf officiel.

Ne « commentez » pas au hasard en production un vendredi : vous cassez la boutique et vous ne savez plus ce qui était pirate. Travail sur copie, bascule, test.

Si Apache ignore htaccess (AllowOverride), la règle pirate est peut-être dans le vhost — là, c'est l'hébergeur. Demandez, ne supposez pas.

Nginx et les cousins

Pas de htaccess lu par défaut. Les règles sont dans la config serveur. Un mutualisé « Nginx » peut quand même exposer un fichier `.htaccess` *ignoré* — ou un module qui le lit. Demandez le modèle. Une migration Apache → Nginx mal calquée laisse des règles mortes *et* d'autres dans le vhost que vous ne voyez pas en FTP.

Les CDN (règles au bord) : une redirect pirate peut vivre chez Cloudflare, pas sur le disque. Inventaire des page rules / workers après incident. Clés du compte CDN.

IIS : même discipline de copie du `web.config`.

Après : permissions et uploads

Le htaccess des uploads peut *devenir* votre filet (pas d'exécution) — à poser *vous*, propre, documenté. Distinguez filet légitime et ligne pirate. 777 : un dossier world-writable se refait un htaccess tout seul.

Une backdoor réécrit le fichier la nuit. Chasse portes + durcissement, pas seulement un joli bloc permalink.

Test mobile 24–48 h. Si la redirect revient, cause 1–4 des 48 heures.

Preuve et réinfection

La copie pirate sert à l'hébergeur, à Google (« voilà ce qui redirigeait »), à l'assureur. Ne la laissez pas en `.htaccess` « pour l'avocat » en production.

Documentez le chemin de chaque fichier trouvé. Une phrase dans le constat si cloaking / phishing.

Créer un espace si plusieurs niveaux et un Nginx opaque. Joignez les copies, pas une capture de « ça redirige » seule.

• Copier avant d'éditer.
• Tous les dossiers, pas la racine seule.
• Filet uploads ensuite, porte d'abord.