Wer das hier liest hat ein Problem, ein großes Problem - seine Scripte laufen nicht mehr. Und man hat in der Regel nicht einmal etwas geändert. Aber jetzt erstmal: Nur die Ruhe, keine Panik kriegen, das bekommen wir schon wieder hin.
Wen betrifft dieser Text überhaupt?
Nun, der typische Anwender mit den beschriebenen Problemen zeigt folgende Merkmale:
a) sein Provider oder er selbst haben ein aktuelles PHP in Version 4.2 oder höher laufen. Möglicherweise auch niedrigere Versionen, aber das ist eher untypisch.
b) wenn er eine Datei wie die folgende ausführt
<?php
phpinfo();
?>
entdeckt er eine Zeile die ihm sagt, dass "register_globals" auf "Off" geschaltet ist.
c) er verwendet Variablen, die "in der URL" (per GET-Request) übergeben werden und diese sind "auf einmal nicht mehr da". Analog natürlich auch für POST-Requests, Cookies etc.
Auf wen das obige nicht zutrifft, der braucht diesen Artikel nicht mehr weiter zu lesen und darf wieder Panik bekommen. Der gesamte Rest findet hier Erleuchtung.
Was ist passiert?
Nun, diese Frage stellt sich den meisten zwar nicht zuerst, aber wie will man ein Problem lösen, dessen Ursache man nicht kennt? Also:
In PHP gibt es eine Einstellung, die in der zentralen Konfigurationsdatei - der php.ini - getätigt werden kann und sich register_globals nennt. Diese ist dafür zuständig, dass Variablen direkt unter ihrem namen verfügbar sind, also bei einem Aufruf von "index.php?seite=test" eine Variable $seite existiert und "test" enthält. Diese ist eigentlich ganz praktisch, aber auch eine gefährliche Falle wie wir später sehen werden.
Jedenfalls haben sich die Entwickler von PHP entschlossen, diese Einstellung ab PHP 4.2 auszuschalten. Die Variablen werden also in der Standardkonfiguration nicht mehr so wie früher zur Verfügung gestellt.
Wieso haben die das gemacht?
Die Überlegungen hinter dieser Entscheidung sind für uns normale Anwender auf den ersten Blick ziemlich mysteriös: Wieso sollte jemand so etwas praktisches Ausschalten?
Folgendes Beispiel:
Ein Admin darf über ein Script in einem Script eine zu löschende Datei auswählen, wobei natürlich nur ungefährliche Dateien zur Auswahl stehen. Der Dateiname wird überprüft und in einer Session gespeichert - somit steht dort ein sicherer Wert, also eine Datei die er auch Löschen darf. Nun wird ein Löschscript aufgerufen und erwartet aus der Session in der Variable $delme den Dateiamen und löscht dann die Datei.
Bisher hört sich das noch nicht tragisch an, was aber wenn jetzt jemand das Script wie folgt aufruft:
delete.php?delme=delete.php
Richtig, der Wert aus der Session wird überschrieben und unser Script (oder jede andere Datei mit entsprechenden Rechten) gelöscht.
Das Beispiel mag an den Haaren herbeigezogen wirken, aber in der Tat findet man häufig Scripte die solche Sicherheitslücken haben, auch wenn sie dort nicht so tragisch wirken. Die Entwickler hatten also allen Grund dieses Verhalten von PHP standardmäßig einzuschränken, um die ausgeführten Scripte sicherer zu machen.
GET? POST? Was ist das?
Wer sich die obigen Fragen beantworten kann, kann diesen Abschnitt getrost überspringen, aber hier wird später benötigtes Basiswissen vermittelt.
Es handelt sich hinter diesen kurzen Wörtchen wie "GET-Request" oder "POST-Request" darum, wie Werte an den Webserver übertragen werden. Dabei handelt es sich um zwei ziemlich verschiedene Vorgehensweisen:
Bei einem GET-Request werden die Daten innerhalb der Anfrage der Seite an den Server aufgenommen - man sieht die Variablen also in der Adresszeile des Browsers.
Ein POST-Request geht jedoch anders vor und überträgt die Daten zwar auch beim Aufruf der Seite an den Server, aber außerhalb der Adresse der Seite in speziell dafür vorgesehenen Teilen der Anfrage - der Benutzer sieht die Daten also nicht in der Adresszeile.
Es ist, um das Problem lösen zu können, wichtig zu wissen, wie die Daten an den Server übertragen werden. Generell kann man dies aber auch an seinem eigenen HTML-Quelltext erkennen:
Wenn man ein Formular verwendet findet sich im <FORM>-Tag in der Regel eine Option METHOD. Sollte dort stehen METHOD="POST" so ist die Übertragungsmethode klar zu erkennen - ebenso bei METHOD="GET". Sollte sich keinerlei Angabe dazu finden, so ist von einem GET-Request auszugehen.
Wenn man absolut keine Ahnung hat, woher seine Daten nun kommen hilft auch ein phpinfo() im Script. Dort sieht man dann am unteren Ende der langen Liste alle übergebenen Werte und - wichtiger - wie diese übergeben wurden.
Und wie werde ich das los?
Nachdem nun klar ist, was passiert ist und wieso dies so passiert ist geht es an die wohl wichtigste frage: Wie bringe ich meine Scripte wieder zum laufen?
Nun, hier heißt es zuerst kurz Luft holen, da hier je nach größe der Scripte einiges an Arbeit auf einen zukommen kann.
Statt in Zukunft direkt auf eine Variable $test zuzugreifen findet dieser Zugriff über bestimmte vordefinierte Arrays statt. Wichtig ist es hierbei zu wissen, wie die Daten übergeben werden (siehe dazu obigen Abschnitt über GET und POST), da hiervon das zu verwendende Array abhängt.
Der erste Schritt dazu seine Scripte wieder flott zu machen besteht also darin, festzustellen und am besten irgendwo eine Liste zu erstellen (je nach Aufwand des Scriptes) welche Variablen wie wohin übergeben werden. Das wird wohl die meiste Zeit und die meisten Nerven in Anspruch nehmen - hier hilft es selbst mal wieder durch die eigene nternetseite zu surfen und alle Formulare und per GET übergebene Variablen genau anzusehen.
Nachdem wir nun wissen welche Variablen woher kommen können wir unser Script endlich an die neuen Gegebenheiten anpassen.
An per GET übergebene Variablen kommen wir in Zukunft über das Array $HTTP_GET_VARS[] oder das Array $_GET[].
Beispiel: Unsere Variable wird über text.php?seite=text übergeben - dann erhalten wir "text" über $HTTP_GET_VARS["seite"] oder $_GET["seite"].
Analog kommen wir an unsere POST-Variablen: $HTTP_POST_VARS[] oder $_POST[].
Die Aufgabe besteht nun - nachdem wir ja schon wissen welche Variablen ersetzt werden müssen - darin, jede $variable aus einem GET-Request in $_GET["variable"] (auf die Unterschiede zwischen den beiden Arrays gehe ich später ein) und jede POST-Variable von $variable in $_POST["variable"] zu übersetzen.
Kurz oder Lang?
Nachdem das Script jetzt hoffentlich wieder funktioniert kann man sich ja höherem widmen: Wann $_GET[] und wann $HTTP_GET_VARS[]?
Nun, für die lange Variante spricht vor allem, dass die Kurformen erst ab PHP-versionen ab 4.1 existieren. Wenn man jedoch eine solche Version verwenden kann sollte man der kurform den Vorzug geben. Warum? Zum einen ist diese um einiges kürzer und somit weniger Tipparbeit. Zum anderen haben die Arrays der Kurzschreibweise ein zusätzliches Merkmal: Sie sind "superglobal".
Das heißt: Innerhalb von Funktionen kann man ebenso über $_GET["meinevariable"]auf seine Daten zugreifen - die vorherige "bekanntmachung" mittels global kann entfallen - somit ist eine weitere häufige Fehlerquelle beseitigt.
Okay, aber es geht noch nicht alles!!!
Was noch immer nicht funktioniert ist jedoch eines: Wir kommen noch immer nicht an unsere Sessions, unsere Cookies und Sachen wie die IP des Besuchers. Die Lösung hier ist jedoch denkbar einfach, da analog zu den schon gesehenen:
$HTTP_SESSION_VARS[] oder besser $_SESSION[] enthält unsere in einer Session gesicherten Daten.
$HTTP_COOKIE_VARS[] oder $_COOKIE[] erfüllt die selbe Funktion für in Cookies gespeicherten Variablen.
Und last but not least $HTTP_SERVER_VARS[] bzw $_SERVER[] enthält vom Server vorbesetzte Variablen wie $_SERVER["REMOTE_ADDR"] und andere alte Bekannte.
So, mit diesem Wissen gestärkt sollte auch PHP 4.2 keine große Hürde darstellen. Nur eines noch zum Schluß: Sicher sind schon einige auf die Idee gekommen register_globals einfach wieder einzuschalten und lesen das hier erst garnicht. Wer es dennoch tut sollte sich das einführende Beispiel nochmals ansehen und durch den Kopf gehen lassen.
Dieser Artikel ist ursprünglich von http://www.phptutorials.de/index.php?cat=5&article=28 |
