Hallo, mit meinen Schülern schreibe ich im Moment ganz einfache php-Scripte. Unter SuSE 8.1 war anscheinend "register_globals = On" noch eingetragen. Jetzt musste ich das bei SuSE 8.2 bzw. am neuen Schulserver ändern. Welche Sicherheitsrisiken bekomme ich denn damit? Viele Grüße Dieter
Dieter Kroemer wrote:
Unter SuSE 8.1 war anscheinend "register_globals = On" noch eingetragen.
Welche Sicherheitsrisiken bekomme ich denn damit?
http://www.php.net/manual/de/security.registerglobals.php Da geht's aberr um Probleme deiner Skripte, die von aussen erzeugt werden. Wenn Schueler php-Skripte ohne sehr durchdachte Konfiguration in php.ini und httpd.conf auf deinem Webserver ausfuehren koennen, bist du vor Angriffen von Innen ueberhaupt nicht geschuetzt, egal was register_globals fuer einen Wert hat. open_basedir, upload_tmp_dir, ignore_user_abort, include_path, memory_limit, max_execution_time gehoeren ueber php_admin_value in httpd.conf fuer Schuelerskripte konfiguriert. Ausserdem studiere noch das Kapitel "Safe Mode" im PHP-Manual. http://www.php.net/manual/de/features.safe-mode.php -- Have fun, Peter
Hallo Dieter Am Donnerstag, 26. Juni 2003 14:23 schrieb Dieter Kroemer:
Hallo,
mit meinen Schülern schreibe ich im Moment ganz einfache php-Scripte. Unter SuSE 8.1 war anscheinend "register_globals = On" noch eingetragen. Jetzt musste ich das bei SuSE 8.2 bzw. am neuen Schulserver ändern.
Welche Sicherheitsrisiken bekomme ich denn damit? Siehe hierzu: http://de.php.net/register_globals
Um Deine Formular-Daten wieder verarbeiten zu können, greifst Du jetzt nicht mehr auf $feldname zu, sondern auf die Arrays $_POST['feldname'], bzw $_GET['feldname'] je nachdem, welche Methode Du für das <Form>-Tag gewählt hast. Weitere Globals sind in $_SERVER verborgen. Andere variablen müssen in Functionen jeweils mit: global $variable1, $variable2; bekannt gemacht werden. Ein zurückstellen auf REGISTER_GLOBALS=on ist nicht erforderlich und auch nicht empfehlenswert. Hoffe es war Dir eine Hilfe. CU Thorsten -- Thorsten Körner http://www.123tkShop.org
Hallo nochmal Am Donnerstag, 26. Juni 2003 14:45 schrieb Thorsten Körner:
Hallo Dieter
Am Donnerstag, 26. Juni 2003 14:23 schrieb Dieter Kroemer:
Hallo,
mit meinen Schülern schreibe ich im Moment ganz einfache php-Scripte. Unter SuSE 8.1 war anscheinend "register_globals = On" noch eingetragen. Jetzt musste ich das bei SuSE 8.2 bzw. am neuen Schulserver ändern.
Welche Sicherheitsrisiken bekomme ich denn damit?
Siehe hierzu: http://de.php.net/register_globals
Um Deine Formular-Daten wieder verarbeiten zu können, greifst Du jetzt nicht mehr auf $feldname zu, sondern auf die Arrays $_POST['feldname'], bzw $_GET['feldname'] je nachdem, welche Methode Du für das <Form>-Tag gewählt hast. Weitere Globals sind in $_SERVER verborgen. $_COOKIE und $SESSION hatte ich noch vergessen.
Andere variablen müssen in Functionen jeweils mit: global $variable1, $variable2; bekannt gemacht werden.
Ein zurückstellen auf REGISTER_GLOBALS=on ist nicht erforderlich und auch nicht empfehlenswert. Hoffe es war Dir eine Hilfe.
Es gibt übrigens auch Code-Snippets, mit denen man schnell alte Scripte wieder zum Laufen bringen kann, wenn diese auf register_globals angewiesen sind. Habe ich allerdings selbst noch nie getestet. CU Thorsten -- Thorsten Körner http://www.123tkShop.org
Thorsten Körner wrote:
Es gibt übrigens auch Code-Snippets, mit denen man schnell alte Scripte wieder zum Laufen bringen kann, wenn diese auf register_globals angewiesen sind.
Und durch die wird's genauso unsicher wie mit "register_globals = On". Wirklich nur in der Portierungsphase verwenden. -- Have fun, Peter
On Thu, Jun 26, 2003 at 02:45:04PM +0200, Thorsten Körner wrote:
Um Deine Formular-Daten wieder verarbeiten zu können, greifst Du jetzt nicht mehr auf $feldname zu, sondern auf die Arrays $_POST['feldname'], bzw $_GET['feldname'] je nachdem, welche Methode Du für das <Form>-Tag gewählt hast.
Besser ist es, $_REQUEST["feldname"] zu verwenden, denn so nagelt man sich nicht auf eine spezifische Request-Methode fest. Kristian
On Thu, Jun 26, 2003 at 02:45:04PM +0200, Thorsten Körner wrote:
Um Deine Formular-Daten wieder verarbeiten zu können, greifst Du jetzt nicht mehr auf $feldname zu, sondern auf die Arrays $_POST['feldname'], bzw $_GET['feldname'] je nachdem, welche Methode Du für das <Form>-Tag gewählt hast.
Besser ist es, $_REQUEST["feldname"] zu verwenden, denn so nagelt man sich nicht auf eine spezifische Request-Methode fest. Das ist auf jeden Fall einfacher. Aber läuft man so nicht Gefahr, daß sich übergebene Variablen gegenseitig überschreiben, wenn sie den gleichen Namen
Hallo Kristian Am Donnerstag, 26. Juni 2003 15:31 schrieb Kristian Koehntopp: tragen? Beispiel: Ich möchte auf einer mehrsprachigenSeite die Sprache wechseln. Per Klickauf ein Flaggen-Icon rufe ich nun die Seite in einer anderen Sprache auf und übergebe mit GET die Variable "lang", damit diese dann entsprechend in ein Cookie geschrieben werden kann. Das aufgerufene Script liest nun das $_REQUEST-Array aus, um 'lang' entgegenzunehmen. Mit der Reihenfolge GPC würde das bedeuten, daß zunächst $_GET['lang'] gefunden wird mit dem Wert 'german' anschließend wird der Wert aber gleich wieder überschrieben, weil es noch ein $_COOKIE['lang'] mit dem Wert 'english' gibt. Damit würde die Umstellung der Sprache wieder hinfällig. Oder sehe ich das irgendwie falsch? CU Thorsten
Tach, Am Don, 2003-06-26 um 21.54 schrieb Thorsten Körner:
Beispiel: Ich möchte auf einer mehrsprachigenSeite die Sprache wechseln. Per Klickauf ein Flaggen-Icon rufe ich nun die Seite in einer anderen Sprache auf und übergebe mit GET die Variable "lang", damit diese dann entsprechend in ein Cookie geschrieben werden kann. Das aufgerufene Script liest nun das $_REQUEST-Array aus, um 'lang' entgegenzunehmen. Mit der Reihenfolge GPC würde das bedeuten, daß zunächst $_GET['lang'] gefunden wird mit dem Wert 'german' anschließend wird der Wert aber gleich wieder überschrieben, weil es noch ein $_COOKIE['lang'] mit dem Wert 'english' gibt. Damit würde die Umstellung der Sprache wieder hinfällig. Oder sehe ich das irgendwie falsch?
lang=cookie['lang'] Wenn "set_lang" per post oder get übergeben wird{ setze Cookie "lang" auf den Wert von "setlang" lang=setlang } Gruß, Ratti -- -o) fontlinge | Font management for Linux | Schriftenverwaltung in Linux /\\ http://freshmeat.net/projects/fontlinge/ _\_V http://www.gesindel.de https://sourceforge.net/projects/fontlinge/
Hallo Ratti Am Donnerstag, 26. Juni 2003 23:22 schrieb Joerg Rossdeutscher:
Tach,
Am Don, 2003-06-26 um 21.54 schrieb Thorsten Körner:
Beispiel: Ich möchte auf einer mehrsprachigenSeite die Sprache wechseln. Per Klickauf ein Flaggen-Icon rufe ich nun die Seite in einer anderen Sprache auf und übergebe mit GET die Variable "lang", damit diese dann entsprechend in ein Cookie geschrieben werden kann. Das aufgerufene Script liest nun das $_REQUEST-Array aus, um 'lang' entgegenzunehmen. Mit der Reihenfolge GPC würde das bedeuten, daß zunächst $_GET['lang'] gefunden wird mit dem Wert 'german' anschließend wird der Wert aber gleich wieder überschrieben, weil es noch ein $_COOKIE['lang'] mit dem Wert 'english' gibt. Damit würde die Umstellung der Sprache wieder hinfällig. Oder sehe ich das irgendwie falsch?
lang=cookie['lang'] Wenn "set_lang" per post oder get übergeben wird{ setze Cookie "lang" auf den Wert von "setlang" lang=setlang } Das ist schon klar. Es ging mir um die Falle die darin steckt, wenn man mit $_REQUEST arbeitet und (evtl. unbedacht) gleichlautende Namen verwendet. Wenn man dann den neuen Cookie in der Art lang=$_GET['lang'], ist das kein Problem. Verwendet man aber lang=$_REQUEST['lang'], dann hat man das Problem, daß der Wert zunächst zwar $_GET['lang'] entspricht, aber wenn bereits ein älteres Cookie existiert, dann wird der Wert gleich wieder überschrieben. $_REQUEST['lang'] ist dann gleich $_COOKIE['lang']. Das Script würde dann den Wert für lang so setzen: lang=$_COOKIE['lang'] Es würde also der alte Wert erneut als Cookie gesetzt werden und nicht der gewünschte neue. Das Alles spielt natürlich nur in solch speziellen Situationen eine Rolle. Aber ich bevorzuge daher lieber $_GET, $_POST, $_COOKIE etc alle einzeln
CU Thorsten
On Thu, Jun 26, 2003 at 09:54:20PM +0200, Thorsten Körner wrote:
Besser ist es, $_REQUEST["feldname"] zu verwenden, denn so nagelt man sich nicht auf eine spezifische Request-Methode fest. Das ist auf jeden Fall einfacher. Aber läuft man so nicht Gefahr, daß sich übergebene Variablen gegenseitig überschreiben, wenn sie den gleichen Namen tragen?
Ja, diese Gefahr besteht, wenn man sowohl $_GET["lall"] und $_POST["lall"] hat und beide benötigt, denn in $_REQUEST werden andere Variablen überlagert. Jedoch gibt es ; This directive describes the order in which PHP registers GET, POST, Cookie, ; Environment and Built-in variables (G, P, C, E & S respectively, often ; referred to as EGPCS or GPC). Registration is done from left to right, newer ; values override older values. variables_order = "EGPCS" in der php.ini, sodaß man das steuern kann. Kristian
On Thu, Jun 26, 2003 at 02:23:00PM +0200, Dieter Kroemer wrote:
[ register_globals = on ] Welche Sicherheitsrisiken bekomme ich denn damit?
In der Vergangenheit haben Leute immer wieder PHP-Scripte geschrieben, bei denen Zustand des Programmes in globalen Variablen gehalten wurde. if ($username == "kris" and $password == "geheim") $valid = 1; if ($valid) perform_magic_function(); Da PHP zugleich alle REQUEST-Parameter automatisch in globale Variablen umgewandelt hat, konnte man auf diese Weise viele PHP-Scripte austricksen. http://www.example.com/defektscript?valid=1 Mit register_globals = off werden Scriptparameter nicht mehr zu globalen Variablen, sondern landen in einem eigenen Namensraum ($_REQUEST ist bevorzugt zu benutzen). if ($_REQUEST["username"] == "kris" and $_REQUEST["password"] = "geheim") $valid = 1; if ($valid) perform_magic_function(); Auf diese Weise funktionieren solche Exploits ab Werk nicht mehr. Kristian
Am Donnerstag, 26. Juni 2003 14:23 schrieb Dieter Kroemer:
mit meinen Schülern schreibe ich im Moment ganz einfache php-Scripte. Unter SuSE 8.1 war anscheinend "register_globals = On" noch eingetragen. Jetzt musste ich das bei SuSE 8.2 bzw. am neuen Schulserver ändern.
Und Dank der vielen hiflreichen Erklärungen :-))) muss ich das jetzt wieder zurückstellen auf "off" . Vielen Dank Dieter
participants (5)
-
Dieter Kroemer -
Joerg Rossdeutscher -
Kristian Koehntopp -
Peter Wiersig -
Thorsten Körner