domi: variablen von adressleiste

servus zusammen,

ich hab ein problem. (wie fast jeder hier)

Mir nimmt der browser die variablen die in der adressleiste stehen nicht mit ins script z.b. index.php?var=test

er sagt dann immer undefinierte variable var

liegt das an der php.ini???

Antwort wäre sehr freundlich

danke

Domi

  1. Moin Moin !

    Suche auf http://www.php.net/ nach $_GET.

    Alexander

    --
    Nein, ich beantworte keine Fragen per eMail. Dafür ist das Forum da.
    Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so!"
  2. Hallo domi,

    er sagt dann immer undefinierte variable var

    ich tippe mal auf register_globals=off...
    btw: afaik steht vor der "Fehlermeldung" nur "Notice" - es ist also kein Fehler sondern nur eine Anmerkung (ich nehme mal an, bei dir ist error_reporting recht sensibel eingestellt)

    liegt das an der php.ini???

    ja, da kann man register_globals ändern (aber bitte auf off lassen)

    Grüße aus Nürnberg
    Tobias

    --
    Selfcode: sh:( fo:) ch:? rl:( br:< n4:& ie:% mo:| va:) de:] zu:) fl:( ss:| ls:[ js:|
    1. Servus!,

      ja, da kann man register_globals ändern (aber bitte auf off lassen)

      ja wenn ich on mach dann gehts warum soll ich sie nicht ändern?

      Servus

      Domi

      1. Hallo dmi,

        ja, da kann man register_globals ändern (aber bitte auf off lassen)
        ja wenn ich on mach dann gehts

        nicht auf on stellen, $_GET['var'] verwenden.

        warum soll ich sie nicht ändern?

        schau bitte in </archiv/> ->http://selfsuche.teamone.de/ und lies auch http://www.php.net/security.registerglobals.

        Grüße aus Nürnberg
        Tobias

        --
        Selfcode: sh:( fo:) ch:? rl:( br:< n4:& ie:% mo:| va:) de:] zu:) fl:( ss:| ls:[ js:|
      2. Hiho,

        ja wenn ich on mach dann gehts warum soll ich sie nicht ändern?

        Das hat zwei gründe, die voneinander abhängen. Erst einmal ist PHP gerade im umbruch und dabei dieses REGISTER GLOBALS abzuschaffen und du weisst nicht sicher wie lange diese Fubnktion noch in PHP sein wird. Wenn du also zukunftssichere scripte schreiben willst schreib sie so, das sie auch ohne REGISTER_GLOBALS laufen. Warum machen die bösen Leute von PHP das? Weil es REGISTER_GLOBALS sehr einfach macht unsichere Scripte zu schreiben. So kann ein User durch erraten einer Variable (oder durch Kentniss des Quellcodes) einfach in deinen Code eingtreifen und diesen zu Dingen bringen, die du nicht beabsichtigt hattest. Und sowas ist ziemlich schwer zu schliessen. Zwei kleine Beispiele:

        Bsp A)
        Stell dir vor du schreibst diesen Code (auch wenn der alles andere als gut ist, wird aber sicher öfters so verwendet)

        do{
        $write = fopen("datei_$i.txt", w);
        fclose($write);
        }while($i < 5);

        Sieht doch auf den ersten Blick ganz vernünftig aus um 5 leere Textdateien zu erstellen, oder? Was passiert nun aber wenn ein besucher dieses in die Adressleiste tippt:
        script.php?i=6
        Genau, $i hat plötzlich den Wert 6 und die Abbruchbedingung ist unwahr. Das heisst plötzlich wird dein Script nicht mehr abbrechen und dir die ganze Festplatte mit Dateien zuschreiben

        Bsp B)
        Du hasst folgendes Script für einen Login:
        if($pw == $pw_aus_db){
        $eingeloggt = 1;
        }

        if($eingeloggt == 1){
        lass_den_user_rein();
        }

        Auch das sieht auf den ersten blick nicht unvernünftig aus. Es sei denn jemand ruft dein Script mit script.php?eingeloggt=1 auf...

        Und schon ist er ohne irgendwelche Passwörter eingeloggt.

        Solche Beispiele gibt es tausendfach und ich bin mir sicher es gibt wenige Scripte die nicht irgendwo nen Angriffspunkt über diese Methode haben. Damit dies nicht mehr passiert, musst du nun die Variablen aus der URL oder aus Formularen explizit abholen. Das heisst zufällig wird dir in Zukunft keine Variable mehr über die Adresse untergemogelt.

        Lass dich aber nicht in falsche Sicherheit wiegen. Denn viele Hoster haben REGISTER_GLOBALS noch an. Es bringt dir also gar nichts wenn dein Script mit REGISTER GLOBALS off einwandfrei und sicher funktionieren würde. Es muss mit beiden Methoden sicher sein..

        Marc

        1. hi,

          danke das du mir das jetzt so expliziet erklärt hast

          habs auch verstanden ,o) hab mirs selber schon gedacht ob man nicht scripte so umgehen ...
          naja thx

        2. do{
          $write = fopen("datei_$i.txt", w);
          fclose($write);
          }while($i < 5);

          Sieht doch auf den ersten Blick ganz vernünftig aus um 5 leere Textdateien zu erstellen, oder? Was passiert nun aber wenn ein besucher dieses in die Adressleiste tippt:
          script.php?i=6
          Genau, $i hat plötzlich den Wert 6 und die Abbruchbedingung ist unwahr. Das heisst plötzlich wird dein Script nicht mehr abbrechen und dir die ganze Festplatte mit Dateien zuschreiben

          Dann doch mal dazu eine Frage für mich ist diese Variante generell nicht akzeptabel!

          Das ist doch einfach nur unsauber programmiert, denn wenn ich die Variable mit  $_get[$i] "abhole hat diese doch trotzdem noch den falschen Wert?
          Hat also mit register_globals erst einmal nichts zu tun!?
          Oder würrde mit $get[$i] überprüft ob die Variable tatsächlich von einem Skript auf kommt und wenn könnte ich ja die Variable von einem beliebigen Server abschicken?

          Viele Grüße TomIRL

          Bsp B)
          Du hasst folgendes Script für einen Login:
          if($pw == $pw_aus_db){
          $eingeloggt = 1;
          }

          if($eingeloggt == 1){
          lass_den_user_rein();
          }

          Auch das sieht auf den ersten blick nicht unvernünftig aus. Es sei denn jemand ruft dein Script mit script.php?eingeloggt=1 auf...

          Und schon ist er ohne irgendwelche Passwörter eingeloggt.

          Solche Beispiele gibt es tausendfach und ich bin mir sicher es gibt wenige Scripte die nicht irgendwo nen Angriffspunkt über diese Methode haben. Damit dies nicht mehr passiert, musst du nun die Variablen aus der URL oder aus Formularen explizit abholen. Das heisst zufällig wird dir in Zukunft keine Variable mehr über die Adresse untergemogelt.

          Lass dich aber nicht in falsche Sicherheit wiegen. Denn viele Hoster haben REGISTER_GLOBALS noch an. Es bringt dir also gar nichts wenn dein Script mit REGISTER GLOBALS off einwandfrei und sicher funktionieren würde. Es muss mit beiden Methoden sicher sein..

          Marc

          1. Moin!

            do{
            $write = fopen("datei_$i.txt", w);
            fclose($write);
            }while($i < 5);

            Sieht doch auf den ersten Blick ganz vernünftig aus um 5 leere Textdateien zu erstellen, oder?

            Naja, das Beispiel oben wird, weil $i niemals erhöht wird, auch endlos laufen. Da fehlt irgendwo noch ein $i++. Mindestens.

            Was passiert nun aber wenn ein besucher dieses in die Adressleiste tippt:
            script.php?i=6
            Genau, $i hat plötzlich den Wert 6 und die Abbruchbedingung ist unwahr. Das heisst plötzlich wird dein Script nicht mehr abbrechen und dir die ganze Festplatte mit Dateien zuschreiben

            Das stimmt nicht, denn die Schleife wird am Ende jedes Laufes auf die Abbruchbedingung hin geprüft. Wenn $i schon gleich auf 6 gestellt wird, ist 6 < 5 falsch und die Schleife endet. Gleich nach dem ersten Dateiöffnen.

            Das ist doch einfach nur unsauber programmiert, denn wenn ich die Variable mit  $_get[$i] "abhole hat diese doch trotzdem noch den falschen Wert?

            Wie doof das Beispiel ist, hab ich angemerkt. Dass ich Probleme kriege, wenn ich den Wert von $i oder $_GET['i'] durch den Benutzer bestimmen lasse ("Wieviele Dateien soll ich anlegen? 1.000.000?"), stimmt auch. Wenn ich aber den Wert von $i nicht vom Benutzer bestimmen lasse, also nicht $_GET['i'] verwende, sondern $i intern verwende, dann macht das bei schlechter Programmierung einen Unterschied.

            Schlecht ist eben sowas:

            while ($i < 5)
            {
              //hier irgendwas tun
              $i++
            }

            Wenn $i vorher niemals verwendet wurde, wird es mit 0 initialisiert, und die schleife läuft mit 0, 1, 2, 3 und 4.

            Normalerweise verwendet man aber keine uninitialisierten Variablen. Da könnte sonstwas drinstehen, weil man vielleicht in irgendeiner Include-Datei geschlampt hat und $i schon mit 1325 initialisiert wurde.

            Deshalb ist sowas besser:
            $i = 0;
            while ($i < 5)
            {
              //hier irgendwas tun
              $i++
            }

            Oder (weil es für diese simple Aufgabe kürzer und besser ist - aber identisch in der Funktion):

            for ($i=0; $i<5; $i++)
            {
              // hier irgendwas tun
            }

            :)

            Hat also mit register_globals erst einmal nichts zu tun!?

            Doch. Das Problem mit register_globals sind immer uninitialisierte, globale Variablen. Man wird vor allem diejenigen globalen Variablen mit Werten vorbelegen, bei denen der Programmierer eine Vorbelegung durch den Benutzer garnicht vorgesehen hat. Nicht die vom Programmierer erwarteten Variablen sind das Problem, sondern die unerwarteten!

            $_GET & Co. löst das Problem, indem die erwarteten Variablen vom Programmierer explizit benannt und quasi "abgeholt" werden müssen, während alle unerwarteten Variablen zwar auch in $_GET stehen, aber einfach nicht verwendet werden, wenn der Programmierer sich nicht vollkommen blöde anstellt.

            Das Problem wird _nicht_ durch die Verwendung von $_GET gelöst, sondern durch die Einstellung "register_globals=off". Das ist bei vielen Providern aber leider immer noch nicht der Fall, so dass man trotz Verwendung von $_GET zusätzlich noch darauf achten muß, dass man alle globalen Variablen initialisiert. Insofern führt die Verwendung von $_GET möglicherweise sogar zu größerem Leichtsinn, weil man sich irrtümlich sicher fühlt, obwohl die Sicherheit erst durch eine simple Servereinstellung hergestellt wird.

            Oder würrde mit $get[$i] überprüft ob die Variable tatsächlich von einem Skript auf kommt und wenn könnte ich ja die Variable von einem beliebigen Server abschicken?

            Die Frage sollte oben beantwortet sein. :)

            PS: Den Rest Zitat unten drunter hättest du auch löschen können.

            - Sven Rautenberg

            --
            ss:) zu:) ls:[ fo:} de:] va:) ch:] sh:) n4:# rl:| br:< js:| ie:( fl:( mo:|
            1. Moin Sven,

              Naja, das Beispiel oben wird, weil $i niemals erhöht wird, auch endlos laufen. Da fehlt irgendwo noch ein $i++. Mindestens.

              Naja die Syntax hab ich nicht überprüft, es ging ums Prinzip.

              Das ist doch einfach nur unsauber programmiert, denn wenn ich die Variable mit  $_get[$i] "abhole hat diese doch trotzdem noch den

              Schlecht ist eben sowas:

              while ($i < 5)
              {
                //hier irgendwas tun
                $i++
              }

              Wenn $i vorher niemals verwendet wurde, wird es mit 0 initialisiert, und die schleife läuft mit 0, 1, 2, 3 und 4.

              Normalerweise verwendet man aber keine uninitialisierten Variablen. Da könnte sonstwas drinstehen, weil man vielleicht in irgendeiner Include-Datei geschlampt hat und $i schon mit 1325 initialisiert wurde.

              Hab ich auch mal so gelernt.

              Hat also mit register_globals erst einmal nichts zu tun!?

              Doch. Das Problem mit register_globals sind immer...

              Vielen Dank mein Knoten im Hirn ist wieder raus.

              Das Problem wird _nicht_ durch die Verwendung von $_GET gelöst, sondern durch die Einstellung "register_globals=off". Das ist bei vielen Providern aber leider immer noch nicht der Fall, so dass man trotz Verwendung von $_GET zusätzlich noch darauf achten muß, dass man alle globalen Variablen initialisiert. Insofern führt die Verwendung von $_GET möglicherweise sogar zu größerem Leichtsinn, weil man sich irrtümlich sicher fühlt, obwohl die Sicherheit erst durch eine simple Servereinstellung hergestellt wird.

              Ich denke, dss viele Provider die Umstellung fürchten, weil die Nutzer sämtliche Skripte umbauen müßten.

              Die Frage sollte oben beantwortet sein. :)

              PS: Den Rest Zitat unten drunter hättest du auch löschen können.

              Hab ich auch schon bemerkt, hab mich schon gewundert warum er 25% angemeckert hatte, mir aber nichts bei gedacht, war nämlich unter der Bildschirmkante verschwunden.

              Viele Grüße auc Berlin

              TomIRL

  3. Hi,

    Mir nimmt der browser die variablen die in der adressleiste stehen nicht mit ins script z.b. index.php?var=test

    Was hat der Browser mit dem PHP-Script zu tun?
    Er bekommt nur dessen Ausgabe.
    PHP läuft auf dem Server, nicht im Browser.

    er sagt dann immer undefinierte variable var
    liegt das an der php.ini???

    Vermutlich (register_globals ==> $_GET/$_POST usw.)
    cu,
    Andreas

    --
    Der Optimist: Das Glas  ist halbvoll.  - Der Pessimist: Das Glas ist halbleer. - Der Ingenieur: Das Glas ist doppelt so groß wie nötig.
    http://mud-guard.de/? http://www.andreas-waechter.de/ http://www.helpers.de/
    1. sers,

      Was hat der Browser mit dem PHP-Script zu tun?
      Er bekommt nur dessen Ausgabe.
      PHP läuft auf dem Server, nicht im Browser.

      ich weis ,o) und das is auch gut so. aber mit dem browser (bzw. der Adresse) kann ich zusätzliche Befehle an das Script senden die es dann auswertet.... egal

      Klingt Komisch is aber so!

      trotzdem danke

      cu

      domi