allow_url_fopen

Dieses allow_url_fopen erlaubt es eben, dass an gewissen Stellen / bei gewissen Funktionen nicht nur eine lokale Datei eingebunden / aufgerufen werden kann, sondern eben auch eine externe (über den Wrapper). Natürlich hat das möglicherweise Konsequenzen in Sachen Sicherheit, das liegt aber weniger an der Funktion als solche, sondern viel mehr an den Scripten, die sie verwenden.

Du versuchst da oben also per getimagesize() auf ein Bild zuzugreifen, das nicht lokal auf Deinem Server liegt. Dazu brauchst Du den http-Wrapper oder wie ich zur Datenübertragung den SSH-Wrapper. Also man muss da dann schon aufpassen, was die Systeme da so aufrufen, ob das feste Vorgaben sind oder eventuell von Usereingaben vorgegeben wird.

Ein echo file_get_contents(domain-mit-schadcode.net); wäre unter Umständen nicht sonderlich gut.

Eingestellt wird es in der php.ini. Entweder in der globalen oder in einer eigenen, falls es sowas gibt - seit PHP 4.3.4. Bei Versionen davor geht es auch per ini_set() in der htaccess. Der Defaultwert von allow_url_fopen ist allerdings 1, eben weil es keine Sicherheitslücke öffnet, sondern 0 nur versucht eine mögliche im Script zu "schließen".

Hi CC,

kannst Du prüfen indem Du die Zeile:

phpinfo();

einfügst.
Und dann hiernach suchst.
[ATTACH=CONFIG]262[/ATTACH]

Gruß

Und ja, wenns off ist kanns nur über die php.ini geändert werden.
Ob Du dafür den Alex brauchst, vllt. über AdminCp

Zitat

Dann werd ich mal die php.ini suchen gehen.

schau mal im Bereich
/etc/php5/apache2 (wenn mod_php)
oder bei
/etc/php5/cgi (wenn FCGI)
Kann aber auch bei Dir im Dir liegen, je nach Serverconfig.

Alternativ, wohl schneller und genauer. In der phpinfo() oben die Zeilen 5, 6, 7 und 8 beachten. Da steht, wo die globale Ini liegt, welche verwendet wird und welche zusätzlichen auch eingebunden werden.

nee bei mir gehts einfacher. logg dich in imscp ein und benutz den php editor. da einfach allow url fopen an stellen.

aber ich rate auch davon ab!
fopen frisst was sicherheit, deswegen ist das standardmässig deaktiviert. CURL ist da besser!
Nimmt man eher als fopen-

wennste da hilfe bvrauchst meld dich einfach, dafür bin ich ja da

musste erstmal als admin freischalten, danach als reseller die rechte zuweisen.
wenn du als reseller sagst jau der domain gebe ich für php die möglichkeit fopen einzuschalten und auszuschalten kannste das machen. klar musst du den php editor einschalten vorher. wennste dann als user drinne bist kannste all den kram einschalten oder ausschalten.
ich rate aber davon ab, das einzige was unkritisch ist ist php warnings auszuschalten, da kan nix passieren, aber wennste dann an exec usw ran gehst kann das sehr gefährlich sein.

du kanst halt schadcode nachladen von einer fremden webseite mit fopen.
aber es gibt schlimmeres zB richtwert für register globals, das sollte man immer off haben.
also nicht wild alles auf ja stellen....

wennste fopen brauchst kannste das für die eine Domain einschalten, wennst unbedingt brauchst. ich habe selber auch domains wo ich das ein habe, bisher nix passiert mit dieser einstellung.

wenn man damit sorgsam umgeht, seine installationen immer auf dem neusten stand hält und halt nicht zuviel php rechte gibt, ist das risiko minimiert, aber nie ausgeschlossen, das trotzdem was passieren kann.

auch ohne fopen kann was passieren.
du kannst ja per doain entscheiden, dann ist bei einem erfolgreichen hack versuch in der regel nur eine domain betroffen.

Die Option (egal wo eingestellt), zählt für alle, die auf diese php.ini zugreifen. Wenn das also 5 Hosts sind, die alle das gleiche PHP mit der gleichen .ini nutzen, dann zählt es auch für die 5. Wenn Du die Möglichkeit hast, einzelne .ini pro vhost zu haben, dann ist es auch nur einzeln.

Was passieren kann: Eigentlich so gut wie alles, wenn die Scripte unsicher sind oder der Server kompromittiert wird. Wie oben schon mal kurz geschrieben kannst Du ja per file_get_contents() Inhalte aus einer anderen Datei einlesen und weiterverarbeiten. Wenn nun allow_url_fopen aus ist, dann funktionieren da nur lokale Dateipfade. Ist allow_url_fopen aber an, dann funktionieren da auch externe Pfade, URLs eben. Oder eben auch bei fopen und einige andere Funktionen, die intern Dateisystemoperationen durchführen können.

Wenn Du so was also nutzt und eventuell ungeprüfte Usereingaben verarbeitest, dann kann der unter Umständen eben jede x-beliebige URL aufrufen und Dein Server verarbeitet die Daten dann.

Hauptproblem war früher da vor allem, dass das auch für include() und require() funktionierte. Man konnte also direkt externen PHP-Code einschleusen (wenn das Script fehlerhaft ist)! Dem ist nun aber nicht mehr so. Wird allow_url_fopen aktiviert, dann ist allow_url_include noch immer aus - das muss man nun extra aktivieren.

Auch schön hier nachzulesen:
*** Link veraltet ***

Im Grund bietet das allow_url_fopen also nur einen vorgetäuschten Schutz. Es kann zum einen nicht alle "Angriffe" unterbinden, erschwert aber gleichzeitig die Nutzung des eigenen Systems, wenn man auf externe Daten zugreifen muss. Es ist und bleibt eben eine Sache vom Scriptentwickler, die Scripte sicher zu machen und vom Hoster, den Server sicher zu halten. Aber eben nicht von PHP. Genau aus dem Grund ist die Option bei PHP auch per default aktiviert.

Das steht z.B. auf einer Webseite:

Zitat

Setzen Sie diesen Wert nur auf on, wenn Sie diese Funktionalität unbedingt benötigen. Denn schon ein include($_GET["filename"]) stellt ein erstklassiges Sicherheitsrisiko dar. Hier sind allerdings auch die PHP-Programmierer gefragt. Denn solche Konstruktionen sind leichtsinnig.

*** Link veraltet ***

Das zählt aber eben nicht für PHP 5.2.x, denn da ist der Include() von http nicht möglich. Und grundsätzlich, da es damals ja funktionierte. Ein Programmierer, der so etwas macht, der sollte ganz schnell seinen Beruf wechseln. Es ist schließlich nicht die Aufgabe einer Scriptsprache, die Dummheit eines Programmierers zu beseitigen.

Ansonsten sah man das ja durchaus öfter. Das waren dann so Seiten, wo in der URL ein ?modul=blablub.php stand. Da könnte man dann natürlich jede andere URL eintragen und das eigene Script würde das ausführen. Aber eben auch nur, wenn das Script nicht prüft.

So, soviel dazu. Aber Alex muss ich soweit recht geben, dass cURL besser ist. Zum einen unterliegt es nicht den Speicher- und Laufzeitbeschänkungen von PHP, zum anderen kann es simultan nebenbei laufen. Aber gerade für sowas wie getimagesize() ist es ungeeignet. Um das zu lösen müsste man also mit cURL erst mal das ganze File laden um dann lokal getimagesize() zu verwenden.

nee der ini editor ist jeweils für eine eigene php.ini und gilt bei mir nicht global. macht ja auch sinn.
klar gibt es eine haupt ini und eine für webmailer etc