Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > de.comp.lang.php > #4262

Re: Fehler 500 beim Include / Require

From Thomas 'PointedEars' Lahn <PointedEars@web.de>
Newsgroups de.comp.lang.php
Subject Re: Fehler 500 beim Include / Require
Date 2017-09-18 19:11 +0200
Organization PointedEars Software (PES)
Message-ID <4299327.GXAFRqVoOG@PointedEars.de> (permalink)
References <opjchs$a3v$1@news.albasani.net>

Show all headers | View raw


Klaus Ketelaer wrote:

> 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 …
 
<http://php.net/supported-versions.php>
(ausserdem: <http://php.net/ChangeLog-5.php#5.4.45>)

> 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…)

<http://tty1.net/smart-questions_de.html>

> 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)

  <FilesMatch "^\.ht">
    Require all denied
  </FilesMatch>

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]

<https://httpd.apache.org/docs/2.4/rewrite/flags.html#flag_r>

(Das Beispiel liefert übrigens 500 statt 666, weil 666 kein gültiger 
Response-Code ist :-))

-- 
PointedEars
Zend Certified PHP Engineer <http://www.zend.com/en/yellow-pages/ZEND024953>
<https://github.com/PointedEars> | <http://PointedEars.de/wsvn>
Twitter: @PointedEars2 | Please do not cc me./Bitte keine Kopien per E-Mail.

Back to de.comp.lang.php | Previous | NextPrevious in thread | Next in thread | Find similar


Thread

Fehler 500 beim Include / Require Klaus Ketelaer <spam@spambouncer.de> - 2017-09-16 16:30 +0200
  Re: Fehler 500 beim Include / Require k@rl.pflaesterer.de (Karl Pflästerer) - 2017-09-16 20:29 +0200
  Re: Fehler 500 beim Include / Require Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2017-09-18 19:11 +0200
    Re: Fehler 500 beim Include / Require "Christoph M. Becker" <cmbecker69@arcor.de> - 2017-09-18 19:19 +0200
      Re: Fehler 500 beim Include / Require Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2017-09-18 23:21 +0200
        Re: Fehler 500 beim Include / Require "Christoph M. Becker" <cmbecker69@arcor.de> - 2017-09-19 16:02 +0200
          Re: Fehler 500 beim Include / Require Ulf Volmer <u.volmer@u-v.de> - 2017-09-19 16:14 +0200
            Re: Fehler 500 beim Include / Require Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2017-09-19 16:46 +0200
    Re: Fehler 500 beim Include / Require Klaus Ketelaer <spam@spambouncer.de> - 2017-09-19 23:20 +0200
      Re: Fehler 500 beim Include / Require Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2017-09-19 23:46 +0200
        Re: Fehler 500 beim Include / Require Klaus Ketelaer <spam@spambouncer.de> - 2017-09-20 09:10 +0200
      Re: Fehler 500 beim Include / Require "Christoph M. Becker" <cmbecker69@arcor.de> - 2017-09-20 01:13 +0200

csiph-web