Dans la lignée de N’aidez pas les pirates et arrêtez de tout inclure !, voici un deuxième opus qui reprends la même réflexion mais avec les fichiers index.php.
Quel index ?
Je parle des fichiers index.php contenant la plupart du temps, soit du vide, soit un Silence is golden, voire même je parle du plugin du même nom Silence is Golden Guard. Plugin que je ne recommande pas, vous comprendrez pourquoi à la lecture.
Ce fichier sert à empêcher le listing du contenu des dossiers, si par exemple sur une installation tout fraîche je tape l’adresse /wp-content/plugins/ sur mon site, je vais voir ce genre de chose :
Et montrer la liste des plugins installés (actifs ou non) n’est jamais une bonne chose, il suffit qu’un plugin soit connu pour contenir une faille pour qu’un hacker tente de l’exploiter.
Mieux vaut donc éviter de laisser ce listing traîner, et par la même occasion ne pas utiliser des plugins comme My Plugins.
Le danger ?
Le danger vient du fait que parfois l’exploitation d’une faille permets d’écrire dans un fichier mais pas de créer ce fichier.
Si le fichier index.php se trouve dans un plugin, c’est moins grave dans le sens où, si le hacker connait le chemin vers le dossier du plugin, c’est qu’il a détecté ce plugin chez vous,et donc il a déjà d’autres fichiers php dans lesquels il peut écrire son code malicieux.
Le danger est surtout présent pour le dossier /uploads/ qui n’est pas censé contenir de fichiers php du tout.
Imaginez alors qu’un hacker parvienne à créer un fichier .php dans ce dossier, ça ferait assez mal, c’était ce que faisait la faille MailPoet justement.
Mais maintenant, imaginez que les droits de création de fichiers via fwrite() ou file_put_contents() soient refusés, et seuls les move_uploaded_files() soient autorisés. Ce cas est plus sécurisé car il ne permet la création de fichiers que via l’upload de WordPress et non via un script php maison ou malicieux.
Bien ! Mais … et si un plugin ou une personne avait cru bien faire et m’avait ajouté des index.php vide dans tous mes sous-dossiers ? Et bien le hacker n’aurait alors plus besoin que de modifier, mettre à jour un fichier et non pas le créer, ce qui ne requiert pas les même droits !
En voulant protéger le listing des dossiers, vous avez permis à un hacker d’ajouter du code php malicieux dans votre installation.
Comment vraiment se protéger ?
La vrai protection est d’empêcher ce listing un cran plus haut, c’est à dire directement dans la config apache ou ngnix ou encore IIS, comme ceci :
[pastacode lang=”markup” message=”Apache” highlight=”” provider=”manual” manual=”Options%20-Indexes”/]
[pastacode lang=”markup” message=”Ngnix” highlight=”” provider=”manual” manual=”location%20%2F%20%7B%0A%20%20%20%20autoindex%20on%3B%0A%7D”/]
Pour IIS, il suffit de se rendre dans la configuration du dossier racine puis modifier désactiver l’option Exploration de répertoire.
Dernier point, ce que je dis pour index.php fonctionne avec n’importe quel autre fichier PHP inutile, comme hello.php !
A vous de ne pas aider les hackers à vous pirater, retirer leur des outils !
