nicht angemeldet
PHP copy von URL
Hallo Forum,
ich hatte auf meinem alten Webspace für meine Community eine Funktion aktiv, mit der sie ihre Avatar-Grafik von einer entfernten URL kopieren konnte. Dazu nutze ich die PHP Funktion copy() um auf die URL zuzugreifen. Nach dem Umzug zu einem anderen Hoster funktioniert das nicht mehr. Die Anfrage beim Support sagte, copy und fopen seien aus Sicherheitsgründen abgeschaltet. Ich solle meine User auffordern, die Grafiken auf ihrem PC zu speichern und dann per Form Upload zu übertragen oder mir eine sicherere Methode ausdenken. Nun frage ich mich, was daran sicherer sein sollte. Gibt es überhaupt eine andere Möglichkeit, Dateien von einer URL direkt zu übertragen? Bin schon fast geneigt den Anbieter zu wechseln. Oder ist das eher die Regel, dass solche Funktionen deaktiviert sind?
-
Hallo,
Nun frage ich mich, was daran sicherer sein sollte.
Wenn das nicht entsprechend abgesichert ist, können User verhältnismäßig einfach Schadcode von anderen Seiten einschleusen, auch der Zugriff auf geschützte Dateien auf demselben Server ist dadurch u. Umständen einfach möglich.
Oder ist das eher die Regel, dass solche Funktionen deaktiviert sind?
Ja, durchaus. Zugriff von einem Host auf einen beliebigen anderen ist oft ein großes No-Go.
Du findest auf PHP.net ein paar Workarounds für Dein Problem.
Viele Grüße,
Jörg -
Moin Moin!
ich hatte auf meinem alten Webspace für meine Community eine Funktion aktiv, mit der sie ihre Avatar-Grafik von einer entfernten URL kopieren konnte. Dazu nutze ich die PHP Funktion copy() um auf die URL zuzugreifen. Nach dem Umzug zu einem anderen Hoster funktioniert das nicht mehr. Die Anfrage beim Support sagte, copy und fopen seien aus Sicherheitsgründen abgeschaltet. Ich solle meine User auffordern, die Grafiken auf ihrem PC zu speichern und dann per Form Upload zu übertragen oder mir eine sicherere Methode ausdenken.
Richtig.
Nun frage ich mich, was daran sicherer sein sollte.
PHP ist so eingestellt, nicht versehentlich Code aus bösen Quellen nachladen kann. Irgendwann in gruseliger Vorzeit hielt es jemand wohl für eine gute Idee, die viele File-I/O-Routinen so aufzubohren, dass sie auch URLs statt lokaler Dateinamen verdauen konnten. PHP-Code, der annimmt, diese Funktionen könnten nur lokale Dateinamen öffnen, und der deswegen Daten vom Benutzer mehr oder weniger direkt als Dateinamen benutzt, ist dadurch oft angreifbar, wenn der Benutzer es schafft, den Funktionen eine URL unterzuschieben. Damit kann der Benutzer unter Deinem Account im Worst Case beliebigen PHP-Code ausführen -- z.B. Deine Datenbank und alle Dateien in Deinem Webspace absammeln, Malware-Schleudern installieren, illegales Zeug bei Dir hosten, usw.
Gibt es überhaupt eine andere Möglichkeit, Dateien von einer URL direkt zu übertragen?
Natürlich. Öffne einen Socket und sprich HTTP. Oder noch einfacher: Verlinke auf die Grafik, statt sie selbst zu hosten.
Bin schon fast geneigt den Anbieter zu wechseln.
Das kannst Du natürlich versuchen. Ich halte das Abschalten dieser Sicherheitslücke in PHP für ein Zeichen für einen guten Hoster.
Oder ist das eher die Regel, dass solche Funktionen deaktiviert sind?
Es sollte die Regel sein, weil diese Funktionen extrem unsicher sind.
Alexander
--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so".-
PHP ist so eingestellt, nicht versehentlich Code aus bösen Quellen nachladen kann. Irgendwann in gruseliger Vorzeit hielt es jemand wohl für eine gute Idee, die viele File-I/O-Routinen so aufzubohren, dass sie auch URLs statt lokaler Dateinamen verdauen konnten. PHP-Code, der annimmt, diese Funktionen könnten nur lokale Dateinamen öffnen, und der deswegen Daten vom Benutzer mehr oder weniger direkt als Dateinamen benutzt, ist dadurch oft angreifbar, wenn der Benutzer es schafft, den Funktionen eine URL unterzuschieben. Damit kann der Benutzer unter Deinem Account im Worst Case beliebigen PHP-Code ausführen -- z.B. Deine Datenbank und alle Dateien in Deinem Webspace absammeln, Malware-Schleudern installieren, illegales Zeug bei Dir hosten, usw.
Danke, das leuchtet mir ein. Warum mir das mein Hoster nicht so erklären konnte statt zu sagen "dann denk dir etwas sichereres aus" ist mir nicht ganz begreflich. Und eben wegen diesem rüden Ton (nicht zum ersten Mal) denke ich an einen Wechsel.
Natürlich. Öffne einen Socket und sprich HTTP. Oder noch einfacher: Verlinke auf die Grafik, statt sie selbst zu hosten.
Ausser fopen / fsockopen würde mir da aber nicht mehr viel einfallen. Und das ist eben auch deaktiviert.
Verlinken möchte ich nicht mehr, weil ich dann die Gefahr sehe, dass mir Leute etwas einschleussen. Hatte früher schon Fälle, dass Seiten mit Grafiken plötzlich passwortgeschützt waren (die Passwortabfrage kam dann bei jedem Aufruf meiner Seite mit der Grafik) oder unter gleichem Namen viel größere Grafiken hochgeladen wurden.
-
Hi!
copy und fopen seien aus Sicherheitsgründen abgeschaltet.
PHP ist so eingestellt, nicht versehentlich Code aus bösen Quellen nachladen kann.Das regelt die php.ini-Direktive allow_url_include. Die vom OP genannten Funktionen laden erst einmal keinen Code nach. Man benötigt dazu immer noch ein eval() oder dergleichen, um das geholte Zeug als Code zu interpretieren. Ich halte es für nicht besonders sinnvoll, diese Direktive zu deaktivieren (im Auslieferungszustand ist sie das ebenfalls nicht). Der allgemeine alternative Weg ist, sich umständlich mit fsockopen() die Daten zu besorgen. Und dann steht man an haargenau dem selben Punkt wie nach einem URL-wrappenden fopen(). Wenn man an dieser Stelle irgendeine Sicherheit haben will, müsste man das Schreiben ins Dateisystem generell verhindern, um include und Co. effektiv die Möglichkeit der Nachladung von laufzeiterstelltem Code zu nehmen.
Für das direkte Codenachladen aus fremden Quellen ist eine andere Direktive zuständig: allow_url_include. Diese ist per Default ausgeschaltet und erlaubt/verbietet das Angeben von URLs bei den Inkludefunktionen.
Ich halte das Abschalten dieser Sicherheitslücke in PHP für ein Zeichen für einen guten Hoster.
Ich halte ihn eher für einen der nicht richtig nachgedacht hat oder eine PHP-Version < 5.2.0 laufen hat, die noch nicht zwischen den beiden oben genannte Direktiven unterscheidet.
Lo!
-
Hi!
'tschuldigung, da hab ich doch was anderes geschrieben als gemeint.
copy und fopen seien aus Sicherheitsgründen abgeschaltet.
PHP ist so eingestellt, nicht versehentlich Code aus bösen Quellen nachladen kann.Das regelt die php.ini-Direktive allow_url_include. Die vom OP genannten Funktionen laden erst einmal keinen Code nach. Man benötigt dazu immer noch ein eval() oder dergleichen, um das geholte Zeug als Code zu interpretieren.
Hier dazwischen fehlte ein Satz wie dieser:
Für den URL-Wrapper von Dateisystemfunktionen wie fopen() ist allow_url_fopen zuständig.Ich halte es für nicht besonders sinnvoll, diese Direktive zu deaktivieren (im Auslieferungszustand ist sie das ebenfalls nicht). Der allgemeine alternative Weg ist, sich umständlich mit fsockopen() die Daten zu besorgen. Und dann steht man an haargenau dem selben Punkt wie nach einem URL-wrappenden fopen(). Wenn man an dieser Stelle irgendeine Sicherheit haben will, müsste man das Schreiben ins Dateisystem generell verhindern, um include und Co. effektiv die Möglichkeit der Nachladung von laufzeiterstelltem Code zu nehmen.
Für das direkte Codenachladen aus fremden Quellen ist eine andere Direktive zuständig: allow_url_include. Diese ist per Default ausgeschaltet und erlaubt/verbietet das Angeben von URLs bei den Inkludefunktionen.
Der Absatz ist obsolet, weil ich das schon im ersten Satz behandelt habe.
Ich halte das Abschalten dieser Sicherheitslücke in PHP für ein Zeichen für einen guten Hoster.
Ich halte ihn eher für einen der nicht richtig nachgedacht hat oder eine PHP-Version < 5.2.0 laufen hat, die noch nicht zwischen den beiden oben genannte Direktiven unterscheidet.Lo!
-
-