Path: csiph.com!weretis.net!feeder4.news.weretis.net!news.mb-net.net!open-news-network.org!.POSTED.234.232.197.178.dynamic.wless.lssmb00p-cgnat.res.cust.swisscom.ch!not-for-mail From: Thomas 'PointedEars' Lahn Newsgroups: de.comp.lang.php Subject: Re: Fehler 500 beim Include / Require Date: Mon, 18 Sep 2017 19:11:57 +0200 Organization: PointedEars Software (PES) Lines: 172 Message-ID: <4299327.GXAFRqVoOG@PointedEars.de> References: Reply-To: Thomas 'PointedEars' Lahn Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8Bit Injection-Info: gwaiyur.mb-net.net; posting-host="234.232.197.178.dynamic.wless.lssmb00p-cgnat.res.cust.swisscom.ch:178.197.232.234"; logging-data="25962"; mail-complaints-to="abuse@open-news-network.org" User-Agent: KNode/4.14.2 X-User-ID: U2FsdGVkX1/oIkrWp4HMmm9czqsENExSgjWllVVBXL6P+04iCQc3Gw== X-Face: %i>XG-yXR'\"2P/C_aO%~;2o~?g0pPKmbOw^=NT`tprDEf++D.m7"}HW6.#=U:?2GGctkL,f89@H46O$ASoW&?s}.k+&. ich betreibe seit Jahren einige Root-Server, auf denen PHP-Scripte > laufen, die Text-Dateien von anderen Servern laden und parsen. Das > laden geschieht geschieht per (url_)include. Eine eingebaute PHP-Funktion namens “url_include” gibt es nicht. > So werden z.B. Quellcodes mit Syntax-Highlighting versehen und angezeigt. > > Das klappt seit Jahren wunderbar und ganz ohne Probleme. Für geeignete Werte. Das ist eine riesige Sicherheitslücke! > Nun habe ich, um ein paar Domains auszulagern, zwei VServer von Strato > angemietet und die Homepages dort installiert. Nun passiert Folgendes > auf den VServern: (PHP 5.4.16 (als FPM) / CentOS 7) ^^^^^^ Noch mehr Sicherheitslücken! Vielleicht solltest Du lieber die Gelben Seiten benutzen … (ausserdem: ) > Nur alles, was auf diesen sch**** VServern liegt, kann nirgendwo > anders per include oder require eingebunden werden. Siehe ganz unten. > Noch nicht einmal die VServer können ihre eigenen Dateien aus ihren > eigenen Verzeichnissen per (url_)include einbinden. Siehe oben. > Mal angenommen im root von domain.test liegen zwei Dateien: > index.php > test.ini > > Wenn ich nun in der index.php > > include:('http://domain.test/test.ini') ^ ^ > aufrufe, fliegt mit sofort ein Fehler 500 um die Ohren, Das ist ja kein Wunder: es ist schonmal syntaktisch fchsal. Ausserdem ist es irnkwie umständlich, kann sogar fhcsal sein, wenn .ini auf der anderen Seite bereits durch PHP geparst wird. Weshalb *über HTTP* auf Dateien auf *demselben* Server zugreifen? require_once 'test.ini'; oder require_once __DIR__ . DIRECTORY_SEPARATOR . 'test.ini'; um auf Nummer Sicher zu gehen. > ausgelöst durch > > AH01071: Got error 'PHP message: PHP Warning: > require(http://domain.test/test.ini): Also steht da require('http://domain.test/test.ini'); und _nicht_ include:('http://domain.test/test.ini') Es ist wirklich nicht hilfreich, wenn Du Quelltext aus dem Gedächtnis postest. (Ausserdem könnte man ja mal nach dem Fehlercode googlen, bevor man postet…) > failed to open stream: HTTP request failed! HTTP/1.1 404 Not Found\r\n in > /var/www/vhosts/domain.test/httpdocs/index.php on line 6\n > PHP message: PHP Fatal error: require(): Failed opening required > 'http://domain.test/test.ini'... Ich würde zusätzlich mal die Warnungen einschalten, da sieht man wahrscheinlich mehr: | $ php -d allow_uri_fopen=1 -d allow_url_include=1 -r | 'require("http://domain.test");' | PHP Warning: require(): php_network_getaddresses: getaddrinfo failed: ^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | Name or service not known in Command line code on line 1 | PHP Stack trace: | PHP 1. {main}() Command line code:0 | PHP Warning: require(http://domain.test): failed to open stream: ^^^^^^^^^^^ | php_network_getaddresses: getaddrinfo failed: Name or service not known in ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | Command line code on line 1 | PHP Stack trace: | PHP 1. {main}() Command line code:0 | PHP Fatal error: require(): Failed opening required 'http://domain.test' ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | (include_path='.:/usr/share/php:/usr/share/pear') in Command line code on | line 1 | PHP Stack trace: | PHP 1. {main}() Command line code:0 `---- (Bei .test ist das klar, kann aber je nach DNS-Konfiguration bei ansonsten gültigen URIs auch so sein.) > Der 500er wird immer durch einen 404er ausgelöst, der absoluter Quatsch ^^^^^^^^^^^^^^^^^ > ist. Nicht unbedingt. > Die Dateien kann ich im Browser mit der gleichen Adresse laden. > Nur beim Include gibt es den 500er. In *Deinem* Browser macht die Namensauflösung aber *Dein* DNS-Server bzw. der *Deines* ISPs. Weshalb sollte der DNS-Server eines V*Servers*, sofern vorhanden, dessen Domains auflösen können müssen? Der Zweck dieses Computers ist *Server*, _nicht_ Client. Entscheidend ist also nicht, was Du in Deinem Browser siehst, sondern was Du auf der Konsole des Systems siehst, von dem aus Du den Request machst. Widrigenfalls per cURL. Netzwerk*grundlagen*. > Ich suche mir nun seit 3 Tagen einen Wolf. Natürlich sind Einstellungen > wie "allow_url_fopen = On" und "allow_url_include = On" aktiviert. Wo genau, und wie hast Du das überprüft? > Es muss an irgendeiner Server-Einstellung liegen, aber mir fällt dazu > absolut nichts mehr ein. Abgesehen von Obigem: Web-Server verweigern mitunter aus Sicherheitsgründen die Antwort, wenn sie annehmen, dass auf der anderen Seite kein Web-Browser ist. Vielleicht liegt es also auch am “User-Agent”-Headerfeld. Das könnte man sowohl mit wget(1) als auch curl(1) herausfinden. Unter PHP sogar mit den cURL-Funktionen. Auch bestimmte Dateitypen werden gemäss Dateiname nicht an jeden ausgeliefert. Da könnte ja sonst jeder kommen, und das wäre dann – richtig! – eine *Sicherheitslücke*. Bei Apache 2.4.x gibt es zum Beispiel (IIRC in der Default-Konfiguration) Require all denied Das liefert allerdings keinen Statuscode 500, sondern 403 (Forbidden), wenn man auf .htaccess & Co. zugreifen will. Aber wenn man will, kann man da jeden beliebigen gültigen Statuscode liefern: RewriteEngine on RewriteBase / RewriteRule /\.ht - [redirect=666,last] (Das Beispiel liefert übrigens 500 statt 666, weil 666 kein gültiger Response-Code ist :-)) -- PointedEars Zend Certified PHP Engineer | Twitter: @PointedEars2 | Please do not cc me./Bitte keine Kopien per E-Mail.