« Pour vivre heureux, vivons cachés »
Cette vieille maxime est tout à fait d’actualité quand on parle de WordPress et de ses plugins, d’un point de vue sécurité informatique.
Les voyous qui veulent s’attaquer à votre blog ont en effet plusieurs options : ils peuvent s’attaquer au moteur (le code WP lui même),
mais il est souvent plus facile de s’attaquer à tous les éléments de tuning que vous avez ajouté (les fameux plugins qui font la gloire de WP).
Comment ça marche, pourquoi et comment s’en prémunir ?
Les Footprints
Les footprints (empreintes en Français), ce sont les traces que laissent tel ou tel plugin.
Certaines traces sont évidentes. Par exemple, un plugin peut ajouter un lien en pied de page;
Il peut plus discrètement ajouter un commentaire html dans le code type « powered by WordPress SEO ».
(Discret, pas pour tout le monde d’ailleurs, Google le voit fort bien, mais c’est une autre histoire, j’en parle ailleurs pour les initiés).
Ca, c’est ce qu’on voit et ce à quoi on pense quand on dit « footprint ».
Ce n’est malheureusement pas tout, car chaque plugin se trouve physiquement dans un sous-répertoire de wp-content/plugins , et ça peut se voir…
Idem pour la version de votre WP… Vous avez viré le tag « generator » de votre wp pour cacher sa version 2.4; ok, la belle affaire !
Vous connaissez le fichier readme.html à la racine de votre site, qui fait partie de la distrib WP, et qui affiche.. devinez ?
C’est gênant ?
En quoi est-ce gênant ?
2 aspects à la réponse :
- La sécurité.
Si on sait quels plugins vous utilisez, voir quelle est leur version, il est « facile » de cibler des failles connues et de hacker votre WP.
- Rester sous le radar, garder ses petits secrets.
Pourquoi montrer à Google que l’on est un SEO, que l’on a (cochez les bonnes cases) un plugin d’opti onsite, un plugin de génération de contenu automatique, un aggregateur rss, un auto poster, un plugin de linking automatique…
Pourquoi montrer à ses concurrents qu’on utilise (remplacez ici par le nom de votre plugin super secret et peu connu qui vous ranke dans le top 2 en 3.4 minutes) , ou un plugin de gestion de fermes de blogs ? Hein, pourquoi ?
Entracte
C’est d’ailleurs cette dernière préoccupation de confidentialité qui a déclenché cet article.
bonjour, quel plugin ou tool pour gérer tous ses wordpress (admin, publication, maj…) sur une seule interface. Merci #wordPress
— RaphSEO (@RaphSEO) 18 Février 2014
et surtout :
je précise ma demande du tweet d'avant cela ne doit laisser aucun footprint
— RaphSEO (@RaphSEO) 18 Février 2014
La discussion sur les footprints continue entre spécialistes, avec Julio qui soulève le point qui nous intéresse
@rochdaniel @RaphSEO les plugins installés sont "détectables" via leur lien genre wp-content/plugins/machin
— Julio Potier Ⓦ (@BoiteAWeb) 18 Février 2014
Je vous passe la discussion complète , vous la retrouverez sur Twitter.
In fine, Julio me lance un défi que je ne peux que relever de mon mieux: écrire un article sur le sujet.
En plus Julio m’annonce qu’il m’attend au tournant; mamma mia, va falloir assurer sur ce coup là !
L’objectif
Rentrons un peu dans les détails techniques.
Je précise que ce qui suit est un « WIP », Work in Progress, et qu’il évoluera donc en fonction des retours qui ne vont pas manquer d’arriver 
Ce qu’on veut :
- * cacher totalement la présence des fichiers d’un plugin dans l’arborescence WP
- * cacher le fait qu’on cache un plugin ! (si on cache juste un plugin, c’est qu’il est là. Si on cache tous les plugins, on a des choses à se reprocher)
Les approches existantes
Après un rapide tour d’horizon, j’ai trouvé les conseils suivants:
- désactiver le listing des répertoires comme /wp-content/plugins/, placer un index.php vide dans les répertoires plugins
(ne résoud rien)
- le plugin « silence is golden » qui efface du serveur les readme.txt, screenshot-1.gif des plugins et filtre les php
(visible quand même, non viable avec les mises à jours, ne résoud pas tout)
- bloquer sélectivement les fichiers de wp-content via htaccess
Order deny,allow
Deny from all
<Files ~ « .(xml|css|jpe?g|png|gif|js)$ »>
Allow from all
</Files>
Les fichiers css et images des plugins restent accessibles, les autres fichiers renvoient une erreur, donc on sait qu’ils sont là.
Mon approche
- * Renvoyer une 404 pour les urls du plugin à cacher
- * Utiliser une 404 WP et non la 404 brute du serveur
- * Utiliser le .htaccess
- * Pouvoir contourner pour les plugins qui, coté admin, ont besoin d’accéder à ces fichiers !
Renvoyer une 404 pour une URL donnée ou pour une certaine expression, c’est facile:
Dans le .htaccess,
RewriteRule readme\.txt$ – [R=404,L]
va renvoyer une 404 (serveur) pour tous les fichiers readme.txt du site.
Comme ça se passe en amont de WP, pas de 404 WP.
Il faut donc passer tout ça à WP pour avoir la 404 décorée.
Le .htaccess par défaut utilise
RewriteRule ^index\.php$ – [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
Autrement dit, si le fichier existe, on ne donne pas le traitement à index.php.
Et donc les fichiers plugins (entre autres) ne passent pas par là, ils sont appelés directement.
Toutes les autres urls, les permalinks *que WP doit connaitre pour les router* passent par index.php.
Et si on envoie à index.php une url qu’il ne peut pas connaitre ?
RewriteRule readme\.txt$ /index.php [L]
(à placer avant les règles par défaut de WP)
Bingo ! le routing de WP ne connait pas, vous pouvez aller voir n’importe quel readme.txt de n’importe quel plugin, 404 WP !
Pour passer en 404 tous les fichiers de tous les plugins (risque de souci pour beaucoup de plugins qui ont besoin de leurs fichiers css ou image)
RewriteRule wp-content/plugins /index.php [L]
Pour passer en 404 tous les fichiers d’un seul plugin (soyons malin, ne cachons pas tout, c’est louche)
Par exemple wordpress-seo
RewriteRule wp-content/plugins/wordpress-seo /index.php [L]
(LA ligne dont il est question dans le titre, c’est celle là ! 
)
Les soucis en l’état
Dans le cas du plugin wordpress seo, pas de souci à priori coté public, par contre coté admin on a un peu perdu les fichiers JS et CSS du plugin,
c’est gênant mine de rien 
.
Pour les plugins qui ont absolument BESOIN, coté public, de leurs fichiers, il n’y a pas de miracle : les fichiers seront visibles et accessibles, on ne peut pas cacher tel quel.
Solution: si css, js, images : les recopier en dehors du répertoire du plugin et modifier le plugin.
Pour les plugins qui n’interviennent que dans l’admin (la majorité de ceux que l’on veut cacher en fait), la solution est tout simplement de désactiver la règle du .htaccess pour les admins.
Désactiver pour l’admin
Une approche simple, c’est par exemple d’ajouter avant la RewriteRule une condition sur un cookie :
RewriteCond %{HTTP_COOKIE} !^.*cookie-name.*$ [NC]
On utilise un nom de cookie « secret », qu’on envoie au navigateur lors d’un login admin;
On utilise ce nom de cookie comme condition ci-dessus, et c’est plié.
En conclusion
- On laisse plus de traces qu’on ne le pense
- La sécurité, ça demande du boulot, ça impose des contraintes
Je laisse volontairement la réflexion en l’état pour le moment.
C’est opérationnel tel quel pour ceux qui peuvent mettre les mains dans le cambouis, et surtout pour ceux qui veulent valider ou infirmer la méthode
(je peux me planter en beauté).
Si ça marche bien, qu’il y a un intérêt, je pourrais publier un plugin qui gère cela facilement plugin par plugin
J’attends vos retours !
Updates
David évoque ici : http://www.djibouteam.fr/mainwp-jaime-jaime-pas/ un cas particulier de plugin dont la détection peut mener au hack direct et total de votre blog. Pour ce cas précis (c’est un plugin de contrôle à distance), le cacher ne suffit pas (le cas est plus complexe), mais c’est un bon exemple de comment chaque plugin installé (et parfois même pas activé) ajoute une faille de sécurité potentielle.
Démo
Une petite démo sur un nouveau site :
Sur ce WP j’ai akismet installé et activé (croyez moi sur parole, car je l’ai caché via la méthode de cet article).
Voyez-vous une différence entre
le rep akismet
http://qualispin.fr/wp-content/plugins/akismet/
un fichier php akismet
http://qualispin.fr/wp-content/plugins/akismet/legacy.php
un fichier css utilisé par l’admin
http://qualispin.fr/wp-content/plugins/akismet/akismet.css
et un plugin qui n’existe pas
http://qualispin.fr/wp-content/plugins/akicestceluila/
http://qualispin.fr/wp-content/plugins/akicestceluila/readme.txt
?
Tweeter !
Partager sur Facebook
Plus sur Google+
Voir également:
- cache plug in ligne roset
- cacher fichier grace a un plugin
- cacher les plugins installés dans wordpress
- cacher lutilisation de wordpress de mon site
- plugin masquer url wordpress
- wordpress masquer les plugins
- wp masquer chemins acces code source
J’en parlerais « un peu » la semaine prochaine dans la suite de mon article, mais concernant les footprint de code, on pense en tant que référenceur ,donc Google, qui donne déjà pas mal de choses, mais quand on parle sécurité, il est clair que l’on pense Google Dork mais aussi d’autres moteurs de recherches.
Ce que les gens doivent comprendre c’est qu’il n’y a pas que Google dans la vie, il y a des moteurs de recherches spécialisés pour la recherche de codes sources, il y a des moteurs de recherches spécialisés dans les failles et autres.
Tout ça pour dire que ce n’est pas parce que quelque chose (un plugin, un addon,etc.) est en BackOffice que vous êtes à l’abri.
Sylvain, j’avais pensé à la même chose concernant la 404 de plugins mais comme je le dis déjà en OFF, je ne suis pas encore très à l’aise avec ce CMS même si je l’apprécie fortement, du coup, développer un plugin ou autre dessus, c’est pas encore gagné
. J’adapte juste mes diverses connaissances en fonction de l’endroit où je me trouve 
+1
S’il y a un intérêt palpable, le plugin « clé en main » verra le jour.
Sans tout résoudre bien sur, la sécurité c’est une histoire que ne se termine jamais.
Bonjour et merci pour l’article.
C’est vrai qu’on laisse des failles en permanence ou presque et effectivement, un plugin qui gère cela plugin par plugin serait une bonne idée pour les profils les moins techniques. D’autant plus que l’avantage, s’il est codé par quelqu’un d’attentif aux failles de sécurité, c’est qu’il n’aura pas besoin de se cacher de lui
Je ne suis pas un pro du SEO, donc je ne comprends peut être pas tout, mais j’ai en fait du mal à comprendre l’intérêt de cet exercice.
Niveau sécurité, la « sécurité par obscurité » n’est pas vraiment le meilleur moyen de protéger un système.
Après tout, si une extension populaire a un problème de sécurité, des hackers essaieront de mettre en place des bots qui vont essayer d’attaquer un max de sites, sans vraiment regarder si chaque site utilise le plugin avant de lancer l’attaque.
On l’a vu avec timthumb.php il y a quelques années. Des mois après que le problème ait été réglé, je voyais encore des bots sur certains de mes sites, alors que je n’utilisais pas timthumb.php.
Au lieu de masquer un plugin parce qu’il n’est pas secure, ne vaudrait-il pas mieux changer de plugin ?
Bon par contre tu mentionnes que tu souhaiterais « garder tes petits secrets ». Bon comme je ne suis pas SEO, je ne sais pas du tout de quoi tu parles
Mais j’imagine que si un plugin est sur le repo ou dispo au téléchargement sur certains sites SEO, il n’est pas vraiment secret. Et si c’est un plugin maison, tu n’as pas forcément besoin de créer un readme ?
Je rate quelque chose ?
Salut Jeremy,
Oui, je pense que tu passes à coté du truc.
Je commence par la fin:
« garder les secrets »: je ne parle pas forcément de plugins « secrets », mais du fait que l’utilisation de ce plugin sur mon blog ne regarde que moi, voir est dangereuse si on sait que j’utilise ça.
Hypothèse: Je suis un méchant black hat, je fais un site MFA avec un plugin connu de génération automatique de contenu. Google n’aime pas (à raison). Le plugin n’a aucun besoin d’être accessible ou visible par un visiteur ou un crawler.
Par défaut, il l’est forcément, et ça fait mal.
Même sans avoir rien à se reprocher: J’utilise akismet, j’ai laissé Hello dolly, je mets wordpress seo, un backup de db par défaut avec quelques autres plugins.
Quel est l’intérêt de laisser cette info publique ? Ce que j’installe comme plugin admin ne devrait regarder que moi.
C’est ça aussi, mes petits secrets !
Coté sécurité: il ne s’agit pas, justement, de sécurité par l’obscurité.
Cette technique s’applique aux plugins qui n’ont pas d’interaction http avec le visiteur. Au mieux, ils servent coté admin.
Par défaut, tous les fichiers du plugin, yc les librairies, sont exposés et peuvent servir de point d’entrée, ou de déni de service.
Bien sur, un plugin « parfait » sur un serveur « parfait » n’a idéalement pas de prise. mais un plugin parfait ça n’existe pas vraiment.
En tout cas, on ne peut jamais être certain que tous les plugins qu’on utilise sont en tout temps parfaits.
Avec cette manip, non seulement le plugin est invisible, mais aucun fichier php, librairie, js… ne peut être appelé depuis l’extérieur.
Ce n’est pas juste cacher la misère sous le tapis, c’est l’empêcher de voir le jour. (404 systématique)
Les scanners de faille dont tu parles scannent des urls potentiellement vulnérables, effectivement sans vérifier si le répertoire du dessus existe.
Peu importe. Ici, l’url vulnérable comme l’url du dossier renvoient une 404 sans exécuter une seule ligne de php.
ça précise le contexte ?
Je précise ma pensée en rebondissant sur « Au lieu de masquer un plugin parce qu’il n’est pas secure, ne vaudrait-il pas mieux changer de plugin ? »
Si le plugin n’a pas de raison d’être accessible depuis l’extérieur, pourquoi prendre le risque ?
Tout plugin est potentiellement faillible.
Donc qu’il y ait ou pas de la biere au frigo, je ferme la porte, je dors mieux.
Ca précise en effet, merci.
Je n’avais pas pensé au black hat, et c’est vrai que je m’en fous un peu que les plugins que j’utilise soient publics. Au contraire, j’utilisais meme ce plugin pour afficher tous mes plugins actifs à une époque. Après, je ne suis qu’un blogueur de base donc je n’ai pas vraiment beaucoup de plugins sur mon site…
Même sans parler BH, c’est du ressort de la vie privée.
On ne fait rien de mal, on n’a rien à cacher, jusqu’au jour où ce qu’on a rendu public volontairement, par méconnaissance ou par paresse se retourne contre nous plus tard.
Coté sécurité, je note sur mon échantillon de blogs (je ne parle pas de celui ci, très très mauvais exemple de sécurité) , des tentatives de plus en plus fréquentes et agressives de hacking.
Je vois de plus en plus passer des sites FR, notamment des institutions connues, qui se sont fait défoncer et arrosent le web de pillules bleues, sans que les admins ou les prestataires s’en soient rendus compte.
Donc par défaut, quand une manip simple permet de fermer des portes, je ne me prive pas.
Ca ne profitera qu’à ceux qui ont une approche pro-active de la sécu de leur site, mais c’est déjà ça.
Qu’on ne soit pas d’accord avec le fond, mais pour la forme, ce genre de défi est interessant, même si finalement, on doute enore de sa réelle utilisation, j’aime de genre de challengees.
Le soucis réside donc à cacher un plugin backend car comem tu le dit, le plugin front-end, s’il inclus la moindre css/js, c’est cramé.
Pour cacher côté admin, il faut donc réussir à faire en sorte que :
- requete sur /wp-content/plugins/pluginacacher/ fasse comme une requete sur /wp-content/plugins/404-404 c’est à dire une vraie 404 WordPress sans redirection, car ça je le saurais dans les headers qu’une 301 ou je ne sais quoi a été faite, et l’url ne doit de toute façon pas changer.
Si le plugin a un fichier qui a le droit et le besoin d’être appelé en direct (#bad) c’est cramé aussi
- meme chose avec uen requete sur un fichier direct donc (sauf cas ci dessus)
Je ne suis pas sur non plus que ce soit mega utile de cacher de cette façon, mais comme je dis, pour le défi je suis curieux de voir les efforts et la solution
@Julio, commentaire repêché dans les spams akismet
Pour le comportement coté admin, ça fait bien ce que tu décris, sans différence dans les entêtes, sans redirection.
Tu as testé la solution ?
Ça c’est une nouvelle ! Au moins ça enlèvera quelques failles de wordpress…
Merci
Merci pour l’astuce sur les footprints ! C’est surtout sur le cas des plugins les plus populaires qu’il faut se pencher car les plus juteux aux yeux des personnes mal intentionnées…