Si vous venez chercher des informations sur ce que l’on nomme le Full Path Disclosure ou (FPD) au niveau de WordPress c’est probablement car vous avez eu un problème quelque part qui pourrait conduire à une faille de sécurité.
Qu’est ce qu’une Full Path Disclosure ?
Il s’agit d’une fonction de php qui indique le chemin d’accès d’un fichier dans la fenêtre du navigateur.
Certains malins provoquent volontairement une erreur afin d’afficher ce message, permettant de voir certaines informations et de pouvoir par la suite exploiter certaines vulnérabilités connues.
Dans le cas de wordpress, suite au différentes mises à jours, certaines fonction sont dépréciés et meme certains fichiers contenant ces fonctions n’existent plus au fil des versions.
Toutefois il peut arriver pour diverses raisons que certains fichiers soit toujours présent.
C’est le cas du fichier rss-functions.php situé dans le dossier wp-includes.
Le simple fait de visiter l’URL du fichier rss-functions.php affichera une Fatal Error avec l’affichage du chemin complet du fichier rss-functions.php depuis la racine du serveur.
Fatal error: Call to undefined function _deprecated_file() in /datas/vol12/w4a1b9c5d/var/www/blog-exemple.fr/htdocs/wp-includes/rss-functions.php on line 8
L’erreur de type Full Path Disclosure est obtenu en injectant un ou des caractères inattendu à certains paramètres d’une page web. Le script ne s’attendant pas à l’injection de ce caractère, va retourner ce message d’erreur.
Quel sont les risques d’afficher un Full Path Disclosure ?
Généralement, les ‘FPD’ (abréviation de Full Path Disclosure) ne sont pas vraiment considérés comme des menaces en soi.
ET pour cause, elles ne font qu’afficher un message d’erreur.
Cependant, il ne faut pas oublier que ces messages d’erreurs sont destinés aux développeurs et non aux utilisateurs qui ne s’attendent pas à ce genre d’informations.
De plus, elles divulguent suffisamment d’informations pour permettre de desceller et d’exploiter d’éventuelles vulnérabilités situé ailleurs sur votre site.
Dans tout les cas, mieux vaut les éviter, car les Full Path Disclosure sont toujours un avantage pour les personnes malveillantes.
Comment éviter ou supprimer un FPD ?
La méthode douce et durable : changer le comportement
La meilleure façon d’éviter un message de type Full Path Disclosure sur son serveur de production est de simplement désactiver l’affichage des messages d’erreur par le serveur web.
Non seulement, on comble une éventuelle faille, mais on évite aussi dans le futur d’autres messages de ce type.
Dans un environnement utilisant le serveur web Apache voici deux méthodes possibles:
Soit en éditant la configuration de PHP grace au fichier php.ini
[pastacode lang= »apacheconf » manual= »display_errors%20%3D%20’off' » message= » » highlight= » » provider= »manual »/]
Soit directement depuis le fichier de configuration d’Apache : apache2.conf
[pastacode lang= »apacheconf » manual= »php_flag%C2%A0%20display_errors%C2%A0%20off » message= » » highlight= » » provider= »manual »/]
Dans certains cas, les fichiers .htaccess accepte les directives php_flag mais c’est loin d’être une généralité.
Faites attention à la configuration par défaut de votre hébergeur, chez certains hébergeur web, les serveurs sont configuré avec l’option display_errors = ‘on’ et il n’est pas possible de changer ce paramètre sur off.
C’est par exemple le cas chez le célèbre ‘1&1’.
La méthode ‘ben tant pis’ : on va être pro-actifs, rechercher et traiter au cas par cas
Pour résoudre ce problème, il y’a donc d’autres méthodes encore exploitables.
Ces méthodes, bien qu’universelles et très simples, sont toujours difficiles à mettre en place, car elle génère inutilement du stress et de la crainte. Sans oublier qu’elle demande à passer un peu plus de temps et surtout de bien connaitre les outils que l’on utilise.
Pour commencer, on peut se documenter et savoir si certains fichiers ne doivent surtout pas être lu par un navigateur.
Cela nous permettra de bloquer directement dans la configuration serveur, ou dans un fichier htaccess les fichiers en questions.
En fonction du contexte, on peut directement utiliser une règle de ré-ecriture tel que :
[pastacode lang= »apacheconf » manual= »RewriteRule%20%5Ewp-includes%2F%5B%5E%2F%5D%2B%5C.php%24%20-%20%5BF%5D » message= » » highlight= » » provider= »manual »/]
utile si vous avez déjà pas mal de règles en place et que vous voulez les cumuler au même endroit.
Ou alors, si possible, pour plus de clarté et de compréhension, utiliser un des mod pour bloquer l’accès à certain fichiers :
[pastacode lang= »apacheconf » manual= »%3CFiles%20%22rss-functions.php%22%3E%0AOrder%20Allow%2CDeny%0Adeny%20from%20all%0A%3C%2FFiles%3E%0A%0A%23%20ou%20bien%20%0A%0A%3Cfiles%20rss-functions.php%3E%0A%09%3CIfModule%20mod_authz_core.c%3E%0A%09%09Require%20all%20denied%0A%09%3C%2FIfModule%3E%0A%09%3CIfModule%20!mod_authz_core.c%3E%0A%09%09Order%20allow%2Cdeny%0A%09%09Deny%20from%20all%0A%09%3C%2FIfModule%3E%0A%3C%2Ffiles%3E » message= » » highlight= » » provider= »manual »/]
Cette manière est toutefois encore relativement propre, dans la mesure ou on ne touches pas aux fichiers du CMS, on n’as pas besoins d’en savoir beaucoup sur son fonctionnement, seulement de savoir si il doit pouvoir être accédé ou non directement par le navigateur.
Un peu plus bourrin
Il est également possible de purement et simplement éditer ou supprimer les fichiers qui posent problèmes.
Cela demande d’être suffisamment à l’aise dans le code qui régie le fonctionnement de son site. Et de savoir si notre action ne sera pas veine …
Oui car si il est facile de supprimer un fichier ou d’en modifier son contenu et puis de l’oublier, encore faut-il que nos modifications ne soit pas remplacé de nouveau par un processus de back-up ou de mise à jour.
Dans le cas de WordPress, la suppression pur et simple du fichier rss-functions.php pourrait s’avérer utile. En effet, ce fichier est une relique, remplacé depuis par rss.php lui aussi déprécié et remplacé par class-simplepie.php. Elle n’existe que pour assurer une rétro-compatibilité avec des plugins ou fonctions de thèmes.
Pour les moins bourins d’entre nous, on peut également éditer le fichier pour gérer autrement l’erreur. Mais ces méthodes ne sont vraiment pas recommandables et pouvant être considérées comme du rafistolage, de plus ces deux dernières méthodes ont un inconvenant majeur dans le cas de WordPress : à chaque mise à jour, le fichier rss-functions.php sera re-créé, écrasant à chaque fois vos modifications. il faudra alors penser à renouveler l’opération après chaque mise à jour.
Une remarque sur le sujet ?