nicht angemeldet
Was ist so kritisch an globalen variablen?
Hallo!
Alle machen immer so einen Hype um die ach so gefährlichen Variablen in PHP. Nur verstehen kann ich das ganze nicht wirklich.
Wenn ich an ein Script - egela ob vom eigenen oder von einem bösen Server/Client aus Daten mit GET übergebe: script.php?daten=boese
Was ist jetzt an
<?
$daten = $_GET["daten"];
echo $daten;
?>
sicherer/besser als an
<?
echo $daten;
?>
???
Verstehe das nicht!
Grüße
Andreas
-
Hallo,
Was ist jetzt an
<?
$daten = $_GET["daten"];
echo $daten;
?>sicherer/besser als an
<?
echo $daten;
?>???
Verstehe das nicht!
Du weißt genau, woher die Daten kommen. (GET, POST, Cookie, Session, Server, Environment) Bei $_GET ist das kein so großes Problem. Aber mal angenommen, Du hasst eine Session-Variable $user wo die userid drinnen steht. Was passiert, wenn der Benutzer jetzt script.php?user=0 eingibt, um Admin zu werden. (Gut - es gibt die register-Reihenfolge, aber ist die immer Sichergestellt? Und was ist, wenn Du eine GET/POST-Variable genauso nennen willst wie eine Session-Variable?)
Grüße,
Christian
-
Hi!
Du weißt genau, woher die Daten kommen. (GET, POST, Cookie, Session, Server, Environment) Bei $_GET ist das kein so großes Problem. Aber mal angenommen, Du hasst eine Session-Variable $user wo die userid drinnen steht. Was passiert, wenn der Benutzer jetzt script.php?user=0 eingibt, um Admin zu werden. (Gut - es gibt die register-Reihenfolge, aber ist die immer Sichergestellt? Und was ist, wenn Du eine GET/POST-Variable genauso nennen willst wie eine Session-Variable?)
Ja das verstehe ich, aber ist das schon alles? Darum, das ganze Theater? Ich meine wenn register globals standardmäßig auf "off" steht, bekomme ich mit einigen Seiten Probleme, das ist ne Menge Arbeit!
Grüße
Andreas-
Hallo,
Ja das verstehe ich, aber ist das schon alles? Darum, das ganze Theater? Ich meine wenn register globals standardmäßig auf "off" steht, bekomme ich mit einigen Seiten Probleme, das ist ne Menge Arbeit!
Du brauchst es ja nicht gleich auszuschalten. Wenn Du neue Scripts schreibst, nimm $_GET, $_POST, etc. Und fange langsam an, deine alten Scripts zu überarbeiten. Wenn Du dann damit fertig bist, dann kannst Du es endgültig ausschalten.
Grüße,
Christian
-
Hallo!
Du brauchst es ja nicht gleich auszuschalten. Wenn Du neue Scripts schreibst, nimm $_GET, $_POST, etc. Und fange langsam an, deine alten Scripts zu überarbeiten. Wenn Du dann damit fertig bist, dann kannst Du es endgültig ausschalten.
Leider habe ich nicht überall Kontrolle über die php.ini!
Grüße
Andreas-
Hallo,
Leider habe ich nicht überall Kontrolle über die php.ini!
.htaccess?
oder halt
extract ($_GET, EXTR_OVERWRITE);
extract ($_POST, EXTR_OVERWRITE);
extract ($_COOKIE, EXTR_OVERWRITE);
extract ($_SESSION, EXTR_OVERWRITE);
extract ($_ENV, EXTR_OVERWRITE);
extract ($_SERVER, EXTR_OVERWRITE);an den Anfang jedes Scripts .... :-)
http://www.php.net/manual/en/function.extract.php
Grüße,
Christian
-
Hallo Christian!
.htaccess?
Wie kann mir htaccess da weiterhelfen? Wie kann ich in der htaccess ini-Angaben überschreiben? So eine Möglichkeit suche ich schon lange, kann dazu nur leider nichts finden, hast Du einen Link?
kannte ich gar nicht - danke!
Viele Grüße
Andreas-
Hi.
.htaccess?
Wie kann mir htaccess da weiterhelfen? Wie kann ich in der htaccess ini-Angaben überschreiben? So eine Möglichkeit suche ich schon lange, kann dazu nur leider nichts finden, hast Du einen Link?Einige Quellen sagen dies:
php_value "register_globals" "1"
Q: http://www.demon.nl/eng/support/business/php.htmlandere dieses:
<IfModule mod_php4.c>
php_flag register_globals on
</IfModule>
Q: http://res1.stddev.appstate.edu/horde/chora/co.php/phpwebsite/docs/INSTALL?r=1.20Weitere: http://www.google.com/search?q=register_globals+php.ini+htaccess
MfG, Arne P.
-
Hallo!
Einige Quellen sagen dies:
php_value "register_globals" "1"
Q: http://www.demon.nl/eng/support/business/php.htmlandere dieses:
<IfModule mod_php4.c>
php_flag register_globals on
</IfModule>
Q: http://res1.stddev.appstate.edu/horde/chora/co.php/phpwebsite/docs/INSTALL?r=1.20Das hört sich so an als müsse PHP als Apache Modul laufen? Das wäre schlecht!
Grüße
Andreas-
Hi.
Das hört sich so an als müsse PHP als Apache Modul laufen? Das wäre schlecht!
Wieso schlecht? Ist das bei Dir nicht so? Oder hat das irgendwelche Nachteile?
Wenn es nicht so wäre, könnte man nicht per .htaccess die Konfiguration verändern, da ja nur der Apache darauf zugreift.
Bei meiner lokalen Apache-Installation unter WIN ist PHP als Modul in der httpd.conf eingebunden:
# php for the apache module
LoadModule php4_module c:/php4/sapi/php4apache.dllMfG, Arne P.
-
Hallo!
Wieso schlecht? Ist das bei Dir nicht so? Oder hat das irgendwelche Nachteile?
Als Modul ist PHP potentiell unsicherer. Daher haben die meisten Provider "nur" die CGI-Version laufen.
Wenn es nicht so wäre, könnte man nicht per .htaccess die Konfiguration verändern, da ja nur der Apache darauf zugreift.
Ist ja auch klar, htaccess gehört nunmal zum Apache. Stand auch definitiv in der PHP-Doku, mit htaccess gehts nur wenn PHP asl Apache-Modul läuft. schade...
Grüße
Andreas
-
-
-
-
Moin,
Wie kann ich in der htaccess ini-Angaben überschreiben? So eine Möglichkeit suche ich schon lange, kann dazu nur leider nichts finden, hast Du einen Link?
Ja, und er führt - man glaubt es kaum - auf php.net/manual: http://www.php.net/manual/de/configuration.php.
--
Henryk Plötz
Grüße aus Berlin-
Hi Henryk!
Ja, und er führt - man glaubt es kaum - auf php.net/manual: http://www.php.net/manual/de/configuration.php.
jajaja, bin schon ruhig, Sachen gibts...
Danke!
Grüße
Andreas
-
-
-
-
-
-
-
-
Moin!
Wenn ich an ein Script - egela ob vom eigenen oder von einem bösen Server/Client aus Daten mit GET übergebe: script.php?daten=boese
Wenn du Daten vom User in einer bestimmten Variablen erwartest, ist das ganz und gar nicht böse, und es macht keinen Unterschied, ob du auf $daten oder $_GET['daten'] zugreifst. Du _willst_ ja, daß Daten kommen.
Schlimmer ist allerdings, daß man auf diese Weise auch Variablen definieren kann, die du in deinem Script für was ganz anderes benutzt. _Das_ ist das Problem.
Am besten ist vermutlich ein reales Beispiel. Lies einfach mal meinen Kommentar zu Philipps Script: http://forum.de.selfhtml.org/archiv/2002/6/15268/#m85650. Das Problem ist dort, daß ich per URL-Parameter "?richtig=1" eine Variable setzen kann, die im Skript selbst nicht initialisiert wird, sofern gewisse Bedingungen herrschen. Das ist das gefährliche.
Klar, daß sowas erst dann gezielt ausgenutzt werden kann, wenn man die Variablennamen kennt. Aber gerade bei den typischen Scriptarchiven kriegt man ja den Quelltext und kann nachgucken, welche Variablen benutzt werden und wie man vielleicht einen Fehler ausnutzen kann. Am schlimmsten ist dabei immer, wenn man eigenen Code auf dem fremden Server ausführen lassen kann. Das richtet hundertprozentig den größten Schaden an. include() ist leider für sowas anfällig, weil PHP fopen-wrappers benutzt: Du kannst eben auch http- und ftp-Zugriffe mit include machen und so Code von fremden Servern einbinden.
Und wenn man nicht per URL-Parameter in den Logfiles Spuren hinterlassen will (irgendwie muß man ja die URL des einzubindenden Codes übermitteln), dann nimmt man eben POST in einem Formular. Und auch da würde mit $_GET und $_POST ein Sicherheitsschutz greifen, denn wenn du die Parameter per GET erwartest, kann sie niemand mehr per POST unterjubeln.
Also merken: Die automatische Übernahme von Parametern in Variablen ist böse, und die fopen-wrappers sind böse. Es ist besondere Vorsicht vor allem dann angesagt, wenn der include()-Befehl variable Seiten zum einbinden erhält.
- Sven Rautenberg
-
Hallo!
Und wenn man nicht per URL-Parameter in den Logfiles Spuren hinterlassen will (irgendwie muß man ja die URL des einzubindenden Codes übermitteln), dann nimmt man eben POST in einem Formular. Und auch da würde mit $_GET und $_POST ein Sicherheitsschutz greifen, denn wenn du die Parameter per GET erwartest, kann sie niemand mehr per POST unterjubeln.
Mit den Spuren, ich mache mich aber nicht für irgendwelche Abmahnungen angreifbar, wenn ich Adressdaten... mit GET übergebe, oder? Vor allem bei SSL sollte das ja egal sein bzw. in keinen Logfiles auftauchen, oder?
Also merken: Die automatische Übernahme von Parametern in Variablen ist böse, und die fopen-wrappers sind böse. Es ist besondere Vorsicht vor allem dann angesagt, wenn der include()-Befehl variable Seiten zum einbinden erhält.
Sowas habe ich noch nie gemacht und auch nicht gebraucht. Aber Du hast Recht, mit register-globals off brauche ich mi nicht mehr Sorgen um ALLE Variablen machen, sondrn nur noch um die tatsächlich erwarteten. Das ist in der Tat ein großer Vorteil!
Viele Grüße
Andreas-
Moin!
Mit den Spuren, ich mache mich aber nicht für irgendwelche Abmahnungen angreifbar, wenn ich Adressdaten... mit GET übergebe, oder? Vor allem bei SSL sollte das ja egal sein bzw. in keinen Logfiles auftauchen, oder?
Wie haftbar du bist, entscheidet der Richter. :)
Ansonsten ist eher unwahrscheinlich, daß SSL-gesicherte Seiten Referrer senden. Ist mir jedenfalls noch nicht untergekommen.
- Sven Rautenberg
-
Hi!
Wie haftbar du bist, entscheidet der Richter. :)
Aber darauf würde ich es nur sehr ungerne ankommen lassen ;-)
Aber ich gehe Recht in der Annahme das Dir keine derartige Bestimmung bekannt ist, soll ja keine Rechtsberatung sein ;-)
Grüße
Andreas-
Moin!
Wie haftbar du bist, entscheidet der Richter. :)
Aber darauf würde ich es nur sehr ungerne ankommen lassen ;-)Aber ich gehe Recht in der Annahme das Dir keine derartige Bestimmung bekannt ist, soll ja keine Rechtsberatung sein ;-)
Du bist für den Datenschutz verantwortlich. Da aber ohne SSL sowieso jeder x-beliebige Mitleser die Daten kriegen kann, ist es vermutlich nicht weiter schlimm, wenn die in anderer Leute Logfile landen. Auf die Unsicherheit der Übertragung weist einen jeder Browser hin, sofern man das nicht abgeschaltet hat (eigene Schuld).
Und bei SSL bin ich mir ziemlich sicher, daß nichts an fremde Server gelangt. Allerdings ist das natürlich ein Hoffen, daß durch gegenteilige Programmierung des Browsers schnell zunichte gemacht werden könnte. Dafür ist dann der Hersteller verantwortlich, nicht du.
- Sven Rautenberg
-
-
-
-