Vollständige Pfadangabe auf rss-functions.php


8

Ich habe einige Sicherheitstests für meine WordPress-Apps durchgeführt und festgestellt, dass alle eine vollständige Pfadangabe für die folgende URL enthalten. Ich bin mir sicher, dass dies bereits beantwortet wurde, aber ich kann keine Informationen dazu finden.

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

Die Fehlermeldung beim Aufrufen des Links lautet Aufruf der undefinierten Funktion _deprecated_file () in /home/mydomain/public_html/wp-includes/rss-functions.php in Zeile 8

Ich habe nichts in meinen Themen für RSS.

Bearbeiten: Nach weiteren Recherchen scheint dies auf den meisten WordPress-Sites ein häufiges Problem zu sein. Die Lösungen, die ich online gefunden habe, beheben den Fehler nicht. Sie sagen einfach, dass sie die Fehlerberichterstattung in der php.ini verbergen sollen. Das behebt es jedoch nicht und nicht jeder hat abhängig von seiner Hosting-Situation Zugriff auf die php.ini.


Dies ist kein Sicherheitsproblem.
Fuxia

4
Ich stimme dir nicht zu. Der vollständige Pfad ist eine sehr wertvolle Information für Angreifer.
JediTricks007

Stellen Sie einfach sicher, dass die Dateiberechtigungen korrekt eingerichtet sind und dass diese Informationen für niemanden ohne diese Berechtigungen nutzlos sind. Wenn Ihre Site durch die Offenlegung des lokalen Pfads anfällig ist, haben Sie viel wichtigere Probleme.
Fuxia

2
Meine Dateiberechtigungen sind korrekt eingestellt. Ich möchte nicht, dass dies gezeigt wird und denke, dass es ein berechtigtes Anliegen ist. Ich denke, wenn ich einen einfachen Weg verhindern kann, den vollständigen Pfad meiner Website zu finden, ist das eine positive Sache. Laut owasp muss der Angreifer bei einigen Angriffen den vollständigen Pfad kennen, den er anzeigen möchte. Daher ist es wichtig, dem Angreifer diese Informationen nicht anzuzeigen.
JediTricks007

Antworten:


5

PHP-Dateien im Verzeichnis wp-includes sollten nicht von außen zugänglich sein, sondern nur per WordPress-Code. Eine einfache Lösung hierfür ist die Verwendung von .htaccess-Regeln, um den Zugriff auf * .php-Dateien zu blockieren, die sich im Verzeichnis wp-includes befinden


1
Können Sie ein Beispiel für einen solchen .htaccess geben?
Lucas Bustamante


0

Display_errors sollte auf einer Produktionswebsite deaktiviert sein.

WP Scan greift wp-includes/rss-functions.phpdirekt zu und dies ist der Quellcode ab 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' );

Wenn direkt darauf zugegriffen wird, ist die _deprecated_file()Funktion nicht vorhanden, sodass ein schwerwiegender Fehler ausgegeben wird.

Die Lösung besteht darin, display_errorsauf Serverebene zu deaktivieren . Wenn Ihr PHP unter mod_apache ausgeführt wird, können Sie dies tun, indem Sie diese Zeile zu Ihrer Hauptdatei .htaccess hinzufügen:

php_flag display_errors off

Wenn Sie PHP-FPM verwenden, müssen Sie wahrscheinlich php.ini in Ihrem lokalen Ordner public_html überschreiben.

Auch WordPress ist sich dessen bewusst:

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


-1

Theoretisch ist das , was ich Ihnen sagen werde, gefährlich und sollte wahrscheinlich nicht getan werden, wenn Sie die Dinge auf die "richtige Wordpress-Art" tun.

Praktisch funktioniert dies für unsere Produktionsumgebung.

Die Datei rss-functions.phpist veraltet und wird an weitergeleitet rss.php.

Die Datei rss.phpist seit Version 3.0.0 veraltet. In internen Kommentaren wird empfohlen, stattdessen SimplePie zu verwenden.

So kann die Datei rss-functions.phpsicher gelöscht werden, solange Sie keine alte Legacy-Installation haben und wenn Sie keine Plugins haben, die von dieser Datei abhängen.

Alternativ können Sie Zeile 8 in dieser Datei auskommentieren.


Aus Sicherheitsgründen sollten Sie auch den obigen Vorschlag von @ MarkKaplun unbedingt umsetzen, da diese Datei nicht direkt vom Browser aufgerufen werden soll.


Übrigens stimme ich Ihnen zu, dass die Offenlegung des vollständigen Pfades ein Sicherheitsrisiko darstellt. Aus diesem Grund halten wir WEBROOT auf einem benutzerdefinierten Pfad fern.


2
Das Löschen oder Ändern von Kerndateien ist niemals eine Lösung.
Mark Kaplun
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.