lieber Dag! in cc: lieber Martin! in cc: suse-laptop ganz herzlichen dank!! die listenmitglieder seien um nachsicht gebeten, dies ist die letzte nachricht in dieser nicht listenspezifischen angelegenheit. ich möchte nur den "thread" mit einer meineserachtens guten lösung für das problem abschließen, so daß andere, die irgendwann einmal dasselbe problem haben sollten, das dann beim suchen im netze finden können. ich habe deinen skriptschnipsel noch so umgeschrieben, daß er mir genau die alte form der variablen auswirft, ohne daß ich register_globals auf "on" setzen müßte - also, sehe ich das richtig? - auch ohne die entsprechende Sicherheitslücke. ich brauche es also nur an den anfang meiner bestehenden skripte zu kopieren - und alles läuft wie gehabt! :-) Skript siehe unten! Rainer On Tue, 15 Apr 2003, Dag Kröper wrote:
Date: Tue, 15 Apr 2003 09:01:23 +0200 From: Dag Kröper
To: M.und.R.Gatz@t-online.de Subject: PHP
Wenn du in den HTML-Formularen "POST" als Übertragungsart wählst sollte Dir folgender Code-Schnipsel helfen (der basiert darauf, dass die Option "track_vars" in der php.ini auf on steht (default)):
-----Snip
if (isset ($HTTP_POST_VARS)){ reset($HTTP_POST_VARS); foreach ($HTTP_POST_VARS as $k=>$elem) { ${"deliv_$k"} = $elem; } }
-----Snip
In der ersten Zeile wird überprüft ob diese Variable gesetzt wurde Die zweite Zeile setzt den Zeiger auf den Anfang des Array's Die foreach Schleife läuft über das Array und baut aus jeder Variable die in dem Formular stand und mit übergeben wurde eine Variable in PHP mit dem Namen "deliv_..." (hierbei steht "..." für den Namen der Variable im HTML-Formular) und weist dieser Variablen den übergebenen Wert zu.
Wenn du "GET" als Übertragungsart wählst, ist das analog, nur das Array heisst dann $HTTP_GET_VARS (Das Funktioniert übrigens auch für Cookies)
Dag Kröper
meine version: // redefine the variables contained in the $HTTP_POST_VARS[variable] array: // test functions are commented out - used only when testing the script if (isset ($HTTP_POST_VARS)){ reset($HTTP_POST_VARS); // $i=1; foreach ($HTTP_POST_VARS as $k=>$elem) { // ${"deliv_$k"} = $elem; $$k = $elem; // testing the output: // echo "element $k<br>"; // echo $elem; // echo "<br>element $i<br>"; // echo $k; // echo "<br><br><br>"; // -- happily using linux and pine ! Rainer Gatz anaesthesiologist e-mail: m.und.r.gatz@t-online.de St.Marienkrankenhaus/ Lünen/ Germany http://home.t-online.de/home/320023358589-0001/index.html
hoppla, da habe ich aus versehen zwei "}" gelöscht. das skript- stück muß korrekterweise so gehen: (und das ist dann wirklich die letzt nachricht zu diesem thema!) // redefine the variables contained in the $HTTP_POST_VARS[variable] array: // test functions are commented out - used only when testing the script if (isset ($HTTP_POST_VARS)){ reset($HTTP_POST_VARS); // $i=1; foreach ($HTTP_POST_VARS as $k=>$elem) { // ${"deliv_$k"} = $elem; $$k = $elem; // testing the output: // echo "element $k<br>"; // echo $elem; // echo "<br>element $i<br>"; // echo $k; // echo "<br><br><br>"; // $i++; } } -- happily using linux and pine ! Rainer Gatz anaesthesiologist e-mail: m.und.r.gatz@t-online.de St.Marienkrankenhaus/ Lünen/ Germany http://home.t-online.de/home/320023358589-0001/index.html
Hallo ihr da draußen,
ich habe deinen skriptschnipsel noch so umgeschrieben, daß er mir genau die alte form der variablen auswirft, ohne daß ich register_globals auf "on" setzen müßte - also, sehe ich das richtig? - auch ohne die entsprechende Sicherheitslücke.
Nein, das siehst du eher nicht richtig. Eben das ist nämlich die Sicherheitslücke. Nehmen wir ein Mal an, du hättest eine Seite, auf der man sich anmelden muss. Es gibt normale Benutzer und Administratoren. Und nun, stell dir vor, du würdest zum Beispiel im Script eine Variable nahmens $admin auf true setzen, wenn das Script feststellt, dass du als Administrator angemeldet bist. Und wenn du nicht als Administrator angemeldet bist, wird die Variable $admin garnicht erst gesetzt. Und jetzt ist beispielsweise register_globals auf on bzw. dein umgeschriebener Scriptschnipsel wird ausgeführt. Dann könnte jemand in der URL einfach den Parameter "admin" mit dem Wert "true" angeben, und er wäre als Administrator angemeldet. Und das ist die Sicherheitslücke, denn das war nur ein Beispiel. Auf manchen Seiten kann ein passwortloses Anmelden als Administrator gewaltige Schäden anrichten. Sicherlich, man kann natürlich so programmieren, dass es keine Möglichkeit gibt, über URL-Parameter irgend etwas Unerlaubtes im Script-Ablauf zu verändern, aber man kann ja oft nicht immer alle Variablen im Überblick behalten. Und irgendwann wird es dann passieren, dass auf ein Mal irgend ein Hacker irgend welche Rechte auf irgend welche Daten oder Dateien kriegt... Deswegen: Lieber auf $_POST, $_GET und $_SERVER (und AFAIK auch noch $_ENV und $_COOKIE [Siehe phpinfo()]) umgewöhnen als Sicherheitsrisiko einzugehen. Und kleiner Tipp: Damit du nicht jeden einzelnen Befehl nach irgend welchen Variablen, die du in $_GET o. ä. umändern musst, durchsuchen musst, einfach error_reporting auf 15 setzen, register_globals auf off lassen. Dann kriegst du durch die Warnungen ganz einfach die Zeilennummern heraus und kannst es dort umändern. -- Grüße von hier drinnen, aus Biberach an der Riss (http://www.stadt-biberach.de), Dogfish (http://dogfish.net.tc)
Hallo, Am Samstag, 3. Mai 2003 13:54 schrieb Dogfish [Candid Dauth]: [ ... ]
Nein, das siehst du eher nicht richtig. Eben das ist nämlich die Sicherheitslücke. Nehmen wir ein Mal an, du hättest eine Seite, auf der man sich anmelden muss. Es gibt normale Benutzer und Administratoren. Und nun, stell dir vor, du würdest zum Beispiel im Script eine Variable nahmens $admin auf true setzen, wenn das Script feststellt, dass du als Administrator angemeldet bist. Und wenn du nicht als Administrator angemeldet bist, wird die Variable $admin garnicht erst gesetzt. Und jetzt ist beispielsweise register_globals auf on bzw. dein umgeschriebener Scriptschnipsel wird ausgeführt. Dann könnte jemand in der URL einfach den Parameter "admin" mit dem Wert "true" angeben, und er wäre als Administrator angemeldet. Und das ist die Sicherheitslücke, denn das war nur ein Beispiel. Auf manchen Seiten kann ein passwortloses Anmelden als Administrator gewaltige Schäden anrichten.
ACK, es geht hauptsächlichst um Sicherheistlücken in den eigenen Scripten.
Sicherlich, man kann natürlich so programmieren, dass es keine Möglichkeit gibt, über URL-Parameter irgend etwas Unerlaubtes im Script-Ablauf zu verändern, aber man kann ja oft nicht immer alle Variablen im Überblick behalten.
Jo, trotzdem empfiehlt es sich meiner Meinung nach sicherheitsrelevante Variablen am Anfang des Scriptes abzufragen. Ungefähr so: if($_GET[auth] == "true") { echo "Sie haben keine Berechtigung diesen Bereich zu betreten\n"; exit; } Es gibt für Angreifer nämlich auch evtl. die Möglichkeit eine .htaccess auf den Server zu laden, die die Einstellungen ausser Kraft setzt: php_flag register_globals On Diese Zeile in einer .htaccess würde register_globals für das gesamte Verzeichnis samt Unterverzeichnissen auf on setzen. Willkommen im Haifischbecken ;-) CU Martin ############################ Nur weil du paranoid bist, heisst es nicht, dass sie nicht hinter dir her sind ############################
participants (3)
-
Dogfish [Candid Dauth]
-
M.und.R.Gatz@t-online.de
-
Martin Conrad