Divulgation du chemin complet sur rss-functions.php


8

J'exécutais un test de sécurité sur mes applications WordPress et j'ai remarqué que toutes ont une divulgation complète du chemin sur l'URL suivante. Je suis sûr que cela a déjà été répondu, mais je ne trouve aucune information à ce sujet.

https://mydomains.com/wp-includes/rss-functions.php

Le message d'erreur lorsque vous accédez au lien est Appel à une fonction non définie _deprecated_file () dans /home/mydomain/public_html/wp-includes/rss-functions.php sur la ligne 8

Je n'ai rien dans mes thèmes pour RSS.

Edit: Après de nouvelles recherches, cela semble être un problème commun sur la plupart des sites WordPress. Les solutions que j'ai trouvées en ligne ne corrigent pas réellement l'erreur. Ils disent simplement de cacher le rapport d'erreur dans le php.ini. Cela ne le résout pas et tout le monde n'a pas accès au php.ini en fonction de sa situation d'hébergement.


Ce n'est pas un problème de sécurité.
fuxia

4
Je ne suis pas d'accord avec vous. Le chemin complet est une information très précieuse pour les attaquants.
JediTricks007

Assurez-vous simplement que les autorisations de fichier sont correctement configurées et que ces informations sont inutiles pour quiconque ne dispose pas de ces autorisations. Si votre site est vulnérable en exposant le chemin d'accès local, vous avez des problèmes beaucoup plus importants.
fuxia

2
Mes autorisations de fichier sont définies correctement. Je ne veux pas que cela se manifeste et je pense que c'est une préoccupation valable. Je pense que si je peux empêcher un moyen facile de trouver le chemin complet de mon site, c'est une chose positive. Selon owasp, certaines attaques nécessitent que l'attaquant connaisse le chemin complet qu'il souhaite visualiser. Il n'est donc pas important de montrer ces informations à l'attaquant.
JediTricks007

Réponses:


5

Les fichiers PHP dans le répertoire wp-includes ne doivent pas être accessibles de l'extérieur, ils ne doivent être inclus que par du code wordpress. Pour cela, une solution simple consiste à utiliser les règles .htaccess pour bloquer l'accès aux fichiers * .php qui se trouvent dans le répertoire wp-includes


1
Pouvez-vous donner un exemple d'un tel .htaccess?
Lucas Bustamante


0

Les erreurs d'affichage doivent être désactivées sur un site Web de production.

WP Scan accède wp-includes/rss-functions.phpdirectement, et c'est son code source, à partir de WordPress 4.9.7:

<?php
/**
 * Deprecated. Use rss.php instead.
 *
 * @package WordPress
 */
_deprecated_file( basename(__FILE__), '2.1.0', WPINC . '/rss.php' );
require_once( ABSPATH . WPINC . '/rss.php' );

Lorsqu'elle est accessible directement, la _deprecated_file()fonction n'existe pas, elle génère donc une erreur fatale.

La solution consiste à désactiver display_errorsau niveau du serveur. Si votre PHP fonctionne sous mod_apache, vous pouvez le faire en ajoutant cette ligne à votre fichier .htaccess principal:

php_flag display_errors off

Si vous utilisez PHP-FPM, vous devrez probablement remplacer php.ini dans votre dossier public_html local.

De plus, WordPress en est conscient:

https://make.wordpress.org/core/handbook/testing/reporting-security-vulnerabilities/#why-are-there-path-disclosures-when-directly-loading-certain-files


-1

Théoriquement, ce que je suis sur le point de vous dire est dangereux et ne devrait probablement pas être fait si vous faites les choses de la bonne manière Wordpress.

Pratiquement , cela fonctionne pour notre environnement de production.

Le fichier rss-functions.phpest obsolète et redirige vers rss.php.

Le fichier rss.phpest obsolète depuis la v3.0.0 et les commentaires internes recommandent d'utiliser plutôt SimplePie.

Ainsi, le fichier rss-functions.phppeut être supprimé en toute sécurité tant que vous n'avez pas une ancienne installation héritée et si vous n'avez pas de plugins qui dépendent de ce fichier.

Vous pouvez également commenter la ligne 8 de ce fichier.


Du point de vue de la sécurité, vous devez également mettre en œuvre la suggestion de @ MarkKaplun ci-dessus, car ce fichier n'est pas destiné à être atteint directement par le navigateur.


BTW, je suis d'accord avec vous que divulguer le chemin complet est un risque pour la sécurité; nous gardons WEBROOT à un chemin personnalisé pour cette raison.


2
pour le meilleur et pour le pire, la suppression ou la modification des fichiers de base n'est jamais une solution.
Mark Kaplun
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.