8

I was running some security test on my WordPress apps and noticed that all of them have a full path disclosure on the following url. I am sure this has been answered before but I can't find any information on this.

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

The error message when going to the link is Call to undefined function _deprecated_file() in /home/mydomain/public_html/wp-includes/rss-functions.php on line 8

I don't have any thing in my themes for RSS.

Edit: After further research this seems to be a common problem on most WordPress sites. The solutions that I found online do not actually fix the error. They simply say to hide the error reporting in the php.ini. That doesn't fix it though and not everyone has access to the php.ini depending on their hosting situation.

  • This is not a security problem. – fuxia Sep 19 '15 at 2:45
  • 4
    I disagree with you. The full path is very valuable information to attackers. – JediTricks007 Sep 19 '15 at 2:48
  • Just make sure the file permissions are set up correctly, and that information is useless to anyone without those permissions. If your site is vulnerable by exposing the local path, you have much more important problems. – fuxia Sep 19 '15 at 2:51
  • 2
    My file permissions are set correctly. I do not want this to show and think it is a valid concern. I think that if I can prevent an easy way to find the full path of my site that is a positive thing. According to owasp some attacks require the attacker to know the full path they wish to view. So not showing that information to the attacker is important. – JediTricks007 Sep 19 '15 at 2:58
5

PHP files in the wp-includes directory should not be accessible from the outside, they should only be included by wordpress code. Therefor an easy fix to this is to use .htaccess rules to block access to *.php files that are under the wp-includes directory

  • 1
    Can you give an example of such .htaccess? – Lucas Bustamante Jul 28 '18 at 16:58
1

That is practically the only option, to disable the php error/warning logging. There are 2 options to do it and another one which is not so good:

  • php.ini - in most of the hosting you can change php.ini(even in shared hosting) - .htaccess
  • directly in php files(not recommended)

http://phphtml.info/how-to-fix-wordpress-internal-pathfull-path-disclosurefpd-issue/

0

Display_errors should be disabled on a production website.

WP Scan accesses wp-includes/rss-functions.php directly, and this is it's source code, as of 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' );

When it is accessed directly, _deprecated_file() function does not exist, so it throws a fatal error.

The solution is to disable display_errors on a server level. If your PHP run under mod_apache, you can do it by adding this line to your main .htaccess file:

php_flag display_errors off

If you use PHP-FPM, you will probably have override php.ini in your local public_html folder.

Also, WordPress is aware of that:

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

-1

Theoretically, what I'm about to tell you is dangerous and probably shouldn't be done, if you're doing things the "proper Wordpress way".

Practically, this works for our production environment.

The file rss-functions.php is deprecated, and redirects to rss.php.

The file rss.php has been deprecated since v3.0.0, and internal comments recommend you use SimplePie instead.

So the file rss-functions.php can be safely deleted as long as you don't have an old, legacy installation, and if you have no plugins which depend on this file.

Alternatively, comment out line 8 in that file.


From a security standpoint, you should also definitely implement @MarkKaplun's suggestion above, as this file isn't intended to be hit directly by the browser.


BTW, I agree with you that divulging the full path is a security risk; we keep out WEBROOT at a custom path for that reason.

  • 2
    for better and worse, deleting or changing core files is never a solution. – Mark Kaplun Jan 3 '17 at 5:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.