PHP register_globals
klawischnigg
PHP register_globals
klawischnigg
Rolf BHi there,
ich hab ein leicht jenseitiges Problem. Ich müßte ein ziemlich altes aber umfangreiches PHP-Programm wieder zum Laufen bringen, das die Einstellung "register_globals = On" benötigt. Leider finde ich auf keinem meiner Webserver mehr ein PHP, das diese Einstellung zuläßt. Sogar php5.6-fpm erlaubt das nicht und startet nicht einmal mehr, wenn man diese Anweisung in die php.ini 'reinschreibt.
Meine Frage: kennt jemand irgendeinen Trick, wie man das umgehen oder eine noch ältere PHP-Version installieren kann? Mir wäre wurscht wie, Rechner und Betriebssysteme hab ich genug herumliegen... (also, fast wurscht, ein windows xp mit xampp tue ich mir nicht mehr an😉)
-
Hallo klawischnigg,
register_globals tut ja nichts weiter, als die Einträge von $_REQUEST in globale Variablen zu kopieren. Was gefährlich ist, weil damit Variablen injiziert werden, die man ggf. gar nicht kennt. Oder die man selbst nicht initialisiert, weil man erwartet, dass sie bei erster Verwendung uninitialisert erzeugt werden.
Die stumpfe Lösung ist eine Schleife zu Beginn des Scripts, die über Einträge von $_REQUEST läuft und globale Variablen draus macht.
Das hier könnte gehen:
for ($_REQUEST as $name => $value) { $$name = $value; }Ob die Zuweisung an $$name eine Variable FOO anlegt, wenn in $name "FOO" drin steht, müsste man sich anschauen. Was bis PHP 8.0 ging und ab 8.0 blockiert wird, ist eine Zuweisung an $GLOBALS[$name].
Diese Lösung ist gefährlich und nicht zu empfehlen
Die weniger stumpfe und sicherere Lösung ist die Analyse, welche Variablen das Script erwartet und ein paar Zeilen, die die entsprechenden $_REQUEST-Inhalte in globale Variablen überträgt. Damit kann man dann nicht mehr beliebige Variablen anlegen.
Aber ich befürchte, dass Du diese Analyse nicht hinkriegst (weil der Kot zu verquirlt ist). Denn WENN Du sie hinkriegst, kannst Du ja jede Variable $name, für die Du die Bestückung durch register_globals erwartest, durch $_REQUEST['name'] ersetzen.
Rolf
--
sumpsi - posui - obstruxi-
Hi there,
Die stumpfe Lösung ist eine Schleife zu Beginn des Scripts, das über Einträge von $_REQUEST läuft und globale Variablen draus macht.
Das hier könnte gehen:
for ($_REQUEST as $name => $value) { $$name = $value; }Ja, daran hab ich auch schon gedacht, aber ich wollte es mir eben ersparen, im Code herumzupfuschen.
Diese Lösung ist gefährlich und nicht zu empfehlen
Völlig wurscht, es geht um ein Programm und nicht um eine allgemein verfügbare Webseite.
Aber ich befürchte, dass Du diese Analyse nicht hinkriegst (weil der Kot zu verquirlt ist). Denn WENN Du sie hinkriegst, kannst Du ja jede Variable $name, für die Du die Bestückung durch register_globals erwartest, durch $_REQUEST['name'] ersetzen.
Siehe oben, das zahlt mir keiner. Ausserdem ist das Programm bei einem Kunden noch im Produktiveinsatz - wenn ich da am Sourcecode herumpfusche dann funktioniert unter Garantie nachher irgendetwas anderes nicht mehr. Egal, danke für Deine Anregungen, ich werd' mich wohl doch noch mit xampp herumschlagen müssen oder ich find noch irgendwo ein php5.2 oder so, da ging das auch noch...
-
Lieber klawischnigg,
Ausserdem ist das Programm bei einem Kunden noch im Produktiveinsatz
und daran lässt sich nichts ändern? Also z.B. dem Kunden beibringen, dass das Programm dermaßen verschimmelt ist, dass entweder der Hersteller eine neue Version liefern muss, oder Du es für neuere Versionen gegen <heftig * $stundenlohn> umarbeiten würdest, weil es sonst nicht mehr genutzt werden kann - außer in einer VM mit Windows XP und einem archaischen Xampp.
wenn ich da am Sourcecode herumpfusche dann funktioniert unter Garantie nachher irgendetwas anderes nicht mehr.
Welche Garantie? Und kann man das mit dem Kunden nicht regeln, dass es eine Testphase geben muss, da Du nicht allwissend bist und neue Software ausreichend getestet werden sollte?
Liebe Grüße
Felix Riesterer
-
Hi there,
Ausserdem ist das Programm bei einem Kunden noch im Produktiveinsatz
und daran lässt sich nichts ändern? Also z.B. dem Kunden beibringen, dass das Programm dermaßen verschimmelt ist, dass entweder der Hersteller eine neue Version liefern muss
Ich war der Hersteller, seufz...ist halt schon fast 20 Jahre her.
oder Du es für neuere Versionen gegen <heftig * $stundenlohn> umarbeiten würdest, weil es sonst nicht mehr genutzt werden kann - außer in einer VM mit Windows XP und einem archaischen Xampp.
Die Geschichte ist so, daß die Software (ein Baustellenkalkulationsprogramm) beim Kunden nur mehr zu Archiv- und Nachschauzwecken genutzt wird, nachdem es 15 Jahre im Einsatz war. Aber weil es noch einen aufrechten Wartungsvertrag gibt hätte ich halt einfach gerne eine Möglichkeit, das Programm bei irgendwelchen auftretenden Problemen (die ich eh nicht mehr erwarte, aber es kann ja nicht schaden, auf Eventualitäten vorbereitet zu sein) auf meinem Server zu bearbeiten und zu testen. Das war bis jetzt möglich, aber vor ein paar Tagen ist mir der letzte Windows-Server, den ich zu dem Behufe am Leben erhielt, abgeraucht, und jetzt hab ich nur mehr Linux-Server mit entsprechend neuen (aber leider auch nicht mehr rückwärtskompatiblen) PHP-Versionen. Hab darin zuerst kein Problem gesehen, bis ich draufgekommen bin, was damit alles nicht mehr geht.
wenn ich da am Sourcecode herumpfusche dann funktioniert unter Garantie nachher irgendetwas anderes nicht mehr.
Welche Garantie?
Murphy weiß es.
Und kann man das mit dem Kunden nicht regeln, dass es eine Testphase geben muss, da Du nicht allwissend bist und neue Software ausreichend getestet werden sollte?
Erstens geb ich nicht gern zu, daß ich nicht allwissend bin und der Rest erklärt sich denk' ich eh mit dem im vorigen Absatz Gesagten...😉
-
-
Hallo klawischnigg,
Programm und nicht um eine allgemein verfügbare Webseite.
Damit bleiben nur Attacken von innen… Let's hope for the best 😉
wenn ich da am Sourcecode herumpfusche dann funktioniert unter Garantie nachher irgendetwas anderes nicht mehr
Okay, aber so eine Schleife zu Beginn der PHP Files, die als URL abgerufen werden, ist doch keine große Änderung. Das ist sozusagen eine Kompatibilitäts[bk]rücke. Die Frage ist natürlich, was noch alles den PHP deprecations zum Opfer fiel.
etzt hab ich nur mehr Linux-Server mit entsprechend neuen (aber leider auch nicht mehr rückwärtskompatiblen) PHP-Versionen
Welches Linux genau? Ggf. findest Du davon noch eine ältere Installation, die PHP 5.2 enthält. Man weiß natürlich nicht, ob die Repos aus Sicherheitsgründen entrümpelt wurden.
Mich wundert zwar, dass da nur ein Subrelease ist, aber hier ist der Sourcecode-Stand von PHP 5.2. Kannst Du es ggf. selbst übersetzen?
Rolf
--
sumpsi - posui - obstruxi-
Damit bleiben nur Attacken von innen… Let's hope for the best 😉
Naja. Im Hinblick darauf, wie verrufen
register_globalsschon anno asbach (~15 Jahre) war (Standardeinstellung warregister_globals = Off) wird wohl auch nach einer Übernahme der Variablen noch viel mehr nicht gehen. Und nur der Teufel weiß welche extremen Sicherheitslücken das Zeug noch hat...Zudem wären da noch ein paar alte Ini-Settings zu beachten..
An folgendem stoße ich mich „etwas“:
Siehe oben, das zahlt mir keiner.
Aber weil es noch einen aufrechten Wartungsvertrag gibt
Hm?!
Da es aber um Archivierungszwecke, also keinen produktiven Einsatz geht wäre wohl eine virtuelle Maschine mit einem alten Debian und passenden PHP vertretbar:
https://archive.org/details/Debian_6.0.9
Wahrscheinlich reicht:
https://archive.org/download/Debian_6.0.9/debian-6.0.9-amd64-DVD-1.iso
Hinweise:
-
Keine Updates bei oder nach der Installation (die Dateien gibt es nicht mehr auf den Servern)
-
vielleicht brauchst Du weitere Images - ich bin mir nicht sicher, ob PHP und und Webserver auf der ersten sind.
-
Ich bin mir auch nicht sicher, ob Dein SSH-Client noch mit dem alten Server (womöglich ssh-1) arbeiten will... Es kann also sein, Du musst mit der Konsole im Virtualisierer klarkommen.
Spanien (Valencia) - Kassel mautfrei in zwei Tagen (mit einem Leicht-LKW und 2 Motos auf dem selben) :: Straßen und ich sind „gerädert“.
-
Hi there,
Und nur der Teufel weiß welche extremen Sicherheitslücken das Zeug noch hat...
Naja, das ist in dem Fall genauso relevant wie Sicherheitslücken bei einem Geschirrspüler oder einem Plattenspieler.
An folgendem stoße ich mich „etwas“:
Siehe oben, das zahlt mir keiner.
Aber weil es noch einen aufrechten Wartungsvertrag gibt
Hm?!
Was ist daran so schwer zu verstehen? Das mit dem Wartungsvertrag wäre weder vom Inhalt noch vom Umfang gedeckt.
Da es aber um Archivierungszwecke, also keinen produktiven Einsatz geht wäre wohl eine virtuelle Maschine mit einem alten Debian und passenden PHP vertretbar:
https://archive.org/details/Debian_6.0.9
Wahrscheinlich reicht:
https://archive.org/download/Debian_6.0.9/debian-6.0.9-amd64-DVD-1.iso
Hinweise:
-
Keine Updates bei oder nach der Installation (die Dateien gibt es nicht mehr auf den Servern)
-
vielleicht brauchst Du weitere Images - ich bin mir nicht sicher, ob PHP und und Webserver auf der ersten sind.
-
Ich bin mir auch nicht sicher, ob Dein SSH-Client noch mit dem alten Server (womöglich ssh-1) arbeiten will... Es kann also sein, Du musst mit der Konsole im Virtualisierer klarkommen.
Ja, danke, so etwas in der Richtung wird's vermutlich eh werden. Nur ob ich virtualisiere weiß ich noch nicht, wie gesagt, Rechner hab ich genug herumstehen...😉
-
Ja, danke, so etwas in der Richtung wird's vermutlich eh werden. Nur ob ich virtualisiere weiß ich noch nicht, wie gesagt, Rechner hab ich genug herumstehen...
Naja, der Rechner kann ab abrauchen und Du musst von vorne anfangen. Einmal virtualisiert und ein dann fertiges Image von dem Kram ablegen kann da schon eine gute Idee sein.
-
Hi there,
Ja, danke, so etwas in der Richtung wird's vermutlich eh werden. Nur ob ich virtualisiere weiß ich noch nicht, wie gesagt, Rechner hab ich genug herumstehen...
Naja, der Rechner kann ab abrauchen und Du musst von vorne anfangen. Einmal virtualisiert und ein dann fertiges Image von dem Kram ablegen kann da schon eine gute Idee sein.
Naja, beim Rechner wär's mir wurscht, da steck ich die SSD halt einfach in einen anderen Rechner, bei brauchbaren Betriebssystemem ist das ja überhaupt kein Problem, nur, Du hast natürlich recht, auch eine SSD kann kaputtgehen (wenn sie das auch im Betriebszustand nur sehr selten tut, im Gegensatz zum Aufbewahrungszustand...😉)
-
Naja, beim Rechner wär's mir wurscht, da steck ich die SSD halt einfach in einen anderen Rechner, bei brauchbaren Betriebssystemem ist das ja überhaupt kein Problem
Verstehe ich nicht. Wie willst Du denn Dein PHP (zzgl. bestimmt noch ne ganze mehr Kram / Ahängigkeiten) ohne Virtualisierung via Plug & Play einfach so via SSD migrieren?
-
Naja, beim Rechner wär's mir wurscht, da steck ich die SSD halt einfach in einen anderen Rechner, bei brauchbaren Betriebssystemem ist das ja überhaupt kein Problem
Verstehe ich nicht. Wie willst Du denn Dein PHP (zzgl. bestimmt noch ne ganze mehr Kram / Ahängigkeiten) ohne Virtualisierung via Plug & Play einfach so via SSD migrieren?
Warum sollte PHP weg sein, wenn ich die SSD in einen neuen Rechner stecke? Ich verstehe Deine Frage nicht ganz oder ich steh' auf dem Schlauch, hm...?
Ich boote natürlich auch von dieser SSD. Da ich für diesen Zweck verständlicherweise nicht die neuesten und besten Rechner verwende, sind mir schon einige Webserver eingegangen. Das ist idR überhaupt kein Problem, einfach Platte/SSD 'raus und in einen neuen Rechner. Das einzige was man uU anpassen muß ist die Bezeichnung der Netzwerkschnittstelle...
-
Warum sollte PHP weg sein, wenn ich die SSD in einen neuen Rechner stecke? Ich verstehe Deine Frage nicht ganz oder ich steh' auf dem Schlauch, hm...?
Ich boote natürlich auch von dieser SSD.
Nee, ich stand auf dem Schlauch. Mir war nicht klar, dass Du das komplett konfigurierte System via SSD booten willst.
Bin auf dem Gebiet auch kein Experte, aber mir scheint der Weg über ein virtualisiertes Image dennoch die bessere Wahl... Raketenwurst wird da bestimmt passende Argumente zur Hand haben...
-
Raketenwurst wird da bestimmt passende Argumente zur Hand haben...
Moin. Natürlich kann ich solche zum Besten geben.
- Hardwarekompatibilität
Ich hab jetzt nicht nachgeschaut, aber z.B. mit SSD und Debian 6 wird es schon eng. Da sind wohl mount-options manuell zu setzen. Danach kommen Netzwerktreiber und so weiter… Bei virtuellen Maschinen kann man passende Harware vortäuschen. Freilich hat klawischnigg dafür nach eigener Aussage genug alte Kisten und so lange es kein Desktop wird kann klawischnigg das Argument auch ganz gut beiseite schieben.
- Verfügbarkeit
Ich bin ein füchterlicher Bürokratiehasser, suche lieber eine VM auf meinem NAS als eine SSD in Kisten und Regalen. Bin nicht so der „Zettel-drauf-Kleber und Registrierer“. Auch hier muss klawischnigg wissen was er lieber hat und also tut.
Außerdem kann ich (z.B. mit Cockpit) virtuelle Maschinen bequem und von zu Hause aus (alternativ irgendwo im Schatten eines Wohnmobiles oder ähnlichem) installieren, starten, anhalten und verwalten. Andere würden gerne ihr Geld so verdienen.
- Aufbewahrung
SSDs sollen, so Behauptungen, angeblich nach ca. 3 Monaten ohne Strom damit beginnen, peu a peu Daten verlieren. Seriösere Quellen sprechen von 24 Monaten. Klar kann klawischnigg also ein Backup auf einem NAS ablegen oder alles bei Bedarf neu installieren... oder halt doch virtualisieren.
- Zukunftsfähigkeit
IDE, EIDE, SCSI, SATA, NVME, PCIe - Das sind alles Schnittstellen für Datenträger. Freilich gäbe es da zukünftige Maschinen ohne SATA auch noch USB-Adapter (ob davon gebootet werden kann ist dann eine andere Frage) aber klawischnigg hat ja reichlich alte Maschinen herumstehen. Ich hoffe, gut klimatisiert und es kommt nicht jemand, der oder die ohne Umfrage bei den freiberuflichen Mitarbeitern und Lieferanten „den alten Mist“ rauswerfen lässt weil der Lagerplatz für Bänke, Tische und Deko betrieblicher Grillfeste benötigt wird.
-
-
-
-
-
-
-
-
Hi there,
wenn ich da am Sourcecode herumpfusche dann funktioniert unter Garantie nachher irgendetwas anderes nicht mehr
Okay, aber so eine Schleife zu Beginn der PHP Files, die als URL abgerufen werden, ist doch keine große Änderung. Das ist sozusagen eine Kompatibilitäts[bk]rücke. Die Frage ist natürlich, was noch alles den PHP deprecations zum Opfer fiel.
Ich hab einen echten Spundus und großen Respekt vor unpredictable sideeffects.😉
Mich wundert zwar, dass da nur ein Subrelease ist, aber hier ist der Sourcecode-Stand von PHP 5.2. Kannst Du es ggf. selbst übersetzen?
Muß ich einmal schauen, auf alle Fälle danke für den Link...
-
-
-