Urmel: register_globals = on -->Nachreile

Hallo Forumer!

Leider funktioniert irgendwie bei mir die Suche nichtm daher bitte nicht gleich toben, falls das Thema schon mal da war.

Ich möchte über PHP ein Formular auswerten. Um über die Variablen auf die Werte zuzugreifen muss in der PHP.ini die register_globals auf "on" stehen. Im Kommentar dazu steht, daß man das aber möglichst sein lassen sollte. Gut, ich könnte auch über die HTTP_POST_VARS gehen, aber das mit den Variablen wär doch schon bequemer...;-)

Wißt Ihr ob das wirklich ein Sicherheitsloch ist, wenn ich die Einstellung ändere?

Danke und Grüße

Urmel

  1. Moin!

    Wißt Ihr ob das wirklich ein Sicherheitsloch ist, wenn ich die Einstellung ändere?

    Ja, das ist es definitiv, wenn du ansonsten schlampig programmierst. Es ist dummerweise nur am konkreten Code zu sehen, _ob_ du schlampig programmierst oder nicht. Im Zweifel ist davon auszugehen.

    Damit du nicht soviel tippen mußt: Neuere PHP-Versionen kennen die superglobalen Variablen $_POST, $_GET etc... (IIRC ab Version 4.1). $HTTP_POST_VARS fliegt in Zukunft (Version 4.3) raus.

    - Sven Rautenberg

    1. Hallo Sven,

      kannst Du mir sagen, ob es eigentlich möglich ist, gleichzeitig Werte per GET-String und im Multipart-Teil als POST-Variablen an ein Script zu schicken? Oder schalten die Browser immer automatisch auf Method=Get, wenn man innder URL Werte übergibt?

      Ich habe das bisher noch nicht ausprobiert, weil auch register_globals eingeschaltet ist und ich das nicht einfach abschalten kann.

      Aber die $_GET und $_POST Variablen sollten ja trotzdem belegt sein, oder?

      Grüße

      Tom

      1. Hallo Tom (schon wieder *g*)

        kannst Du mir sagen, ob es eigentlich möglich ist, gleichzeitig Werte per GET-String und im Multipart-Teil als POST-Variablen an ein Script zu schicken? Oder schalten die Browser immer automatisch auf Method=Get, wenn man innder URL Werte übergibt?

        nein, das geht problemlos. Ich habe das beispielsweise in meinem Gästebuch gemacht, da sieht das form so aus:

        <form action="index.php?page=guestbook/entry&entry=set" method="post" ...>

        Ich habe das bisher noch nicht ausprobiert, weil auch register_globals eingeschaltet ist und ich das nicht einfach abschalten kann.

        Aber die $_GET und $_POST Variablen sollten ja trotzdem belegt sein, oder?

        ja, sind sie.

        Fabian

    2. Hallo, Sven,

      Damit du nicht soviel tippen mußt: Neuere PHP-Versionen kennen die superglobalen Variablen $_POST, $_GET etc... (IIRC ab Version 4.1). $HTTP_POST_VARS fliegt in Zukunft (Version 4.3) raus.

      Was, wieso das denn? Zugunsten $_POST? Da muss ich etwas versäumt haben, ich dachte $_POST wäre nur der Bezeichnet für Schreibfaule. Ich verwende nämlich ausschließlich $HTTP_POST_VARS.

      Grüße,
      Mathias

      1. Moin!

        Damit du nicht soviel tippen mußt: Neuere PHP-Versionen kennen die superglobalen Variablen $_POST, $_GET etc... (IIRC ab Version 4.1). $HTTP_POST_VARS fliegt in Zukunft (Version 4.3) raus.

        Was, wieso das denn? Zugunsten $_POST? Da muss ich etwas versäumt haben, ich dachte $_POST wäre nur der Bezeichnet für Schreibfaule. Ich verwende nämlich ausschließlich $HTTP_POST_VARS.

        Dann hast du dich nicht gründlich informiert. :)

        $HTTP_*_VARS ist das klassische Array. Es ist leider ein ganz stinknormales Array, befindet sich also im gleichen ...hm, wie sagt man korrekt... Scope wie alle anderen globalen Variablen - das bedeutet: Willst du aus einer Unterfunktion auf das Array zugreifen, musst du es innerhalb der Funktion mit global $HTTP_*_VARS erst bekannt machen.

        Die neuen Arrays $_* sind superglobal. Man kann aus jedem Kontext heraus auf sie zugreifen, auch innerhalb von Funktionen, ohne die Arrays erst bekannt machen zu müssen.

        Insofern unterscheiden sich die beiden Arrays schon in ihrer Funktion (wenngleich der Unterschied meist kaum zum Tragen kommt).

        - Sven Rautenberg

        1. Hallo, Sven,

          $HTTP_POST_VARS fliegt in Zukunft (Version 4.3) raus.
          Was, wieso das denn?

          Willst du aus einer Unterfunktion auf das Array zugreifen, musst du es innerhalb der Funktion mit global $HTTP_*_VARS erst bekannt machen.

          Das war mir bekannt und so bin ich auch immer vorgegangen.

          Die neuen Arrays $_* sind superglobal. Man kann aus jedem Kontext heraus auf sie zugreifen, auch innerhalb von Funktionen, ohne die Arrays erst bekannt machen zu müssen.

          Aha, das war mir neu. Hat das nur positive Auswirkungen auf die Einfachheit der Verwendung der GPC- und Umgebungsvariablen oder hat das Sicherheitsgründe?

          Insofern unterscheiden sich die beiden Arrays schon in ihrer Funktion (wenngleich der Unterschied meist kaum zum Tragen kommt).

          Und wieso fliegt $HTTP_POST_VARS heraus (meine ursprüngliche Frage)? Ich finde nur: "(...) Damit sind die alten, beziehungsweise die  $HTTP_*_VARS Arrays veraltet." - Wieso muss ich meine Skripte zwangsweise auf $_* anpassen? Bei register_globals war mir das bewusst, aber ich sehe keinen Zuwachs an Sicherheit bei $_*, nur die Verwendung ist komfortabler (weil "chaotischer").

          Grüße,
          Mathias

          1. Hallo Mathias,

            Aha, das war mir neu. Hat das nur positive Auswirkungen auf die Einfachheit der Verwendung der GPC- und Umgebungsvariablen oder hat das Sicherheitsgründe?

            Ich schätze mal, das ist (Zitat von Dir) "für Schreibfaule" gedacht.

            Und wieso fliegt $HTTP_POST_VARS heraus (meine ursprüngliche Frage)? Ich finde nur: "(...) Damit sind die alten, beziehungsweise die  $HTTP_*_VARS Arrays veraltet." - Wieso muss ich meine Skripte zwangsweise auf $_* anpassen? Bei register_globals war mir das bewusst, aber ich sehe keinen Zuwachs an Sicherheit bei $_*, nur die Verwendung ist komfortabler (weil "chaotischer").

            Nun ja, es gibt auch das neue Superglobal $_REQUEST. Darin steht entweder der Inhalt von $_POST oder von $_GET, je nach $_SERVER["REQUEST_METHOD"]. Du könntest natürlich argumentieren, dass man ein $HTTP_REQUEST_VARS hätte einführen können, aber es ist nun mal halt so. Einen *vernünftigen* Grund, wieso die alten Arrays fliegen, gibt's IMHO nicht.

            Ich denke aber, dass die neuen Arrays eingeführt worden sind, weil die Menschliche Faulheit grenzenlos ist. Und die von PHP wollten warscheinlich die Leute anspornen, die sonst schlampigen Code geschrieben haben, endlich mal nicht schlampigen Code zu schreiben. Denn bei $_POST überwindet man sich leichter, es noch hinzuschreiben, als bei $HTTP_POST_VARS. Denn die PHP-Anfänger (weswegen Bio PHP nicht mag) hören nicht auf Sicherheitsfragen.

            Grüße,

            Christian