opi: Behandlung nicht erwarteter Argumente

Hallo zusammen,

mich beschäftigt eine grundlegende Frage bezüglich der Argumente,
die einem Skript übergeben werden und weiß nicht, wie ich Argumente
behandeln soll, die ich nicht erwarte.

Ein kleines Beispiel:

Aus einem Formular heraus erwarte ich die Werte

Name=Schroeder&Vorname=Atze

Nun erhalte ich allerdings noch zusätzlich die Werte wie zum Beispiel

bla=bla

Jetzt weiß ich nicht so recht, was ich damit machen soll. Ist das
vollkommen unwichtig oder sollte ich ziemlich genau die Werte
herausfiltern, die ich auch tatsächlich erwarte und für Werte, die
nicht erwünscht sind, eine Fehlermeldung herausgeben?

Das habe ich einfach mal zum Spaß bei Google ausprobiert

http://www.google.de/search?hl=de&q=selfhtml&btnG=Google-Suche&meta=&bla=bla

und es ist nichts passiert.

Mein Gedanke hierbei ist, dass wenn ich diese Werte nicht filter,
sie dann in meinem Skript rumlungern. Wenn ich aber sowas wie einen
Filter einbaue, ich dabei eine riesen Liste pflegen muss, da die
Funktion ja global genutzt wird.

Greez,
opi

--
Selfcode: ie:( fl:( br:^ va:) ls:] fo:) rl:( n4:? ss:| de:] ch:? mo:|
  1. Hi,

    mich beschäftigt eine grundlegende Frage bezüglich der Argumente,
    die einem Skript übergeben werden und weiß nicht, wie ich Argumente
    behandeln soll, die ich nicht erwarte.

    Ein kleines Beispiel:

    Aus einem Formular heraus erwarte ich die Werte

    Name=Schroeder&Vorname=Atze

    das sind keine Argumente, die einem Script übergeben werden. Das ist ein Teil der Request-URL, nicht mehr. Dieser spezielle Teil wird i.d.R. in der Form analysiert, dass er als Liste von Name/Value-Pairs angesehen wird, zu der eine leichte Zugänglichkeit über den Namen geschaffen wird. Wenn Du mehr darin siehst, begehst Du höchstwahrscheinlich einen schwerwiegenden Fehler.

    Nun erhalte ich allerdings noch zusätzlich die Werte wie zum Beispiel

    bla=bla

    Wenn Dir der Name "bla" nichts sagt, dann brauchst Du ihn augenscheinlich nicht.

    Jetzt weiß ich nicht so recht, was ich damit machen soll. Ist das
    vollkommen unwichtig oder sollte ich ziemlich genau die Werte
    herausfiltern, die ich auch tatsächlich erwarte und für Werte, die
    nicht erwünscht sind, eine Fehlermeldung herausgeben?

    Dies ist vergleichbar mit der Frage, was Du machen sollst, wenn Dein Script feststellt, dass in seiner Umgebung ein Script liegt, welches es nicht kennt. Wieso sollte das interessieren?

    Mein Gedanke hierbei ist, dass wenn ich diese Werte nicht filter,
    sie dann in meinem Skript rumlungern.

    Der Query-String einer URL ist kein Sondermüll, der aufwändig entsorgt werden müsste.

    Cheatah

    --
    X-Self-Code: sh:( fo:} ch:~ rl:° br:> n4:& ie:% mo:) va:) de:] zu:) fl:{ ss:) ls:~ js:|
    X-Self-Code-Url: http://emmanuel.dammerer.at/selfcode.html
    X-Will-Answer-Email: No
    X-Please-Search-Archive-First: Absolutely Yes
    1. Hi,

      Der Query-String einer URL ist kein Sondermüll, der aufwändig entsorgt werden müsste.

      kannst Du diesen Satz bitte erläutern?

      LG
      Chris

      1. Hi,

        Der Query-String einer URL ist kein Sondermüll, der aufwändig entsorgt werden müsste.
        kannst Du diesen Satz bitte erläutern?

        ich halte ihn grammatisch und inhaltlich für nicht besonders schwer zu verstehen. An welcher Stelle hast Du Schwierigkeiten?

        Cheatah

        --
        X-Self-Code: sh:( fo:} ch:~ rl:° br:> n4:& ie:% mo:) va:) de:] zu:) fl:{ ss:) ls:~ js:|
        X-Self-Code-Url: http://emmanuel.dammerer.at/selfcode.html
        X-Will-Answer-Email: No
        X-Please-Search-Archive-First: Absolutely Yes
        1. Hi,

          Der Query-String einer URL ist kein Sondermüll, der aufwändig entsorgt werden müsste.
          kannst Du diesen Satz bitte erläutern?

          ich halte ihn grammatisch und inhaltlich für nicht besonders schwer zu verstehen. An welcher Stelle hast Du Schwierigkeiten?

          Wie soll  an denn mit dem Query-String einer URL umgehen, wenn er nicht gefällig ist? Oder sollte man das gar nicht prüfen? Es interessiert mich eben sehr, was so ein Profi[tm] wie Du empfiehlt. Etwa Togal?

          LG
          Chris

          1. Hallo Chris,

            stell dir einfach vor, du hast von deiner Versicherungsgesellschaft ein Angebot für eine Hausratversicherung angefordert. Nun hast du Post im Briefkasten, und in dem Umschlag von der Versicherung ist außer dem Angebot, das du verlangt hast, auch noch ein Antrag für eine Lebensversicherung, für eine KFZ-Haftpflichtversicherung und für eine Gebäudebrandversicherung. Wie reagierst du?

            Lass mich raten: Du ignorierst die zusätzlichen Angebote?
            Und genau das würde ich mit unerwarteten URL-Parametern auch tun. Einfach nciht beachten.

            Der Query-String einer URL ist kein Sondermüll, der aufwändig entsorgt werden müsste.

            Genau. Lass ihn einfach links liegen, pick das raus, was du brauchst, und lass den Rest einfach verrotten. Passt scho!

            So long,

            martin

            1. Genau,

              und die register_globals-Problematik ist dann so, wie der Briefträgerservice bei uns damals in USA war: Wenn du Post loswerden willst, bringst du sie nicht weg, sondern hängst sie von außen an deinen privaten Briefkasten, der Briefträger nimmt sie dann mit.
              In dem Fall musst du natürlich aufpassen, dass wenn ein Umschlag mit einem Antrag auf eine Lebensversicherung außen am Briefkasten hängt, dies NICHT der ist, den die Gesellschaft dir mit den anderen Sachen zugeschickt hat, sondern einer, den du selbst bearbeitet/erstellt hast.

              Daher: Variablen sauber initialisieren, sonst könnte im schlimmsten Fall jemand bei aktiviertem register_globals von außen an deine Variablen dran. Man muss deshalb nicht die Requests filtern, sondern nur seinen eigenen Code sauber halten...

              MfG
              Rouven

              --
              -------------------
              ss:) zu:) ls:& fo:) de:< va:{ ch:? sh:) n4:( rl:? br:$ js:| ie:) fl:(
            2. Hallo!

              stell dir einfach vor, du hast von deiner Versicherungsgesellschaft ein Angebot für eine Hausratversicherung angefordert. Nun hast du Post im Briefkasten, und in dem Umschlag von der Versicherung ist außer dem Angebot, das du verlangt hast, auch noch ein Antrag für eine Lebensversicherung, für eine KFZ-Haftpflichtversicherung und für eine Gebäudebrandversicherung. Wie reagierst du?

              Das kommt drauf an ob ich eine unfähige Sekretärin habe die einfach alle Briefe auspackt und ob ich dann auch noch alles blind unterschreibe was Sie mir vorlegt ;-)

              Grüße
              Andreas

              --
              SELFHTML Linkverzeichnis: http://aktuell.de.selfhtml.org/links/
              1. Hallo Andreas,

                Das kommt drauf an ob ich eine unfähige Sekretärin habe ...

                nein, du hast das Grundprinzip nicht verstanden:
                Wir sind hier bei _SELF_HTML. Wir haben hier keine Sekretärin, die ist mit dem Briefträger durchgebrannt!  ;-)

                Schönen Abend noch,

                Martin

        2. Hi Cheatah,

          manchmal habe ich den Eindruck, dass Du die Leute hier künstlich verdummen willst, um die Spielchen Deines Arbeitgebers nicht zu gefährden...

          G
          Chris

    2. Guten Abend Cheatah,

      Nun erhalte ich allerdings noch zusätzlich die Werte wie zum Beispiel

      bla=bla

      Wenn Dir der Name "bla" nichts sagt, dann brauchst Du ihn augenscheinlich nicht.

      okay, also einfach links liegen lassen :-)

      Danke für die Antwort.

      Greez,
      opi

      --
      Selfcode: ie:( fl:( br:^ va:) ls:] fo:) rl:( n4:? ss:| de:] ch:? mo:|
      1. Hi,

        Nun erhalte ich allerdings noch zusätzlich die Werte wie zum Beispiel
          bla=bla
        Wenn Dir der Name "bla" nichts sagt, dann brauchst Du ihn augenscheinlich nicht.
        okay, also einfach links liegen lassen :-)

        ja. Allerdings brauchst Du ihn nicht in den Links liegen zu lassen ;-)

        Cheatah

        --
        X-Self-Code: sh:( fo:} ch:~ rl:° br:> n4:& ie:% mo:) va:) de:] zu:) fl:{ ss:) ls:~ js:|
        X-Self-Code-Url: http://emmanuel.dammerer.at/selfcode.html
        X-Will-Answer-Email: No
        X-Please-Search-Archive-First: Absolutely Yes
  2. Hi,

    Jetzt weiß ich nicht so recht, was ich damit machen soll. Ist das
    vollkommen unwichtig oder sollte ich ziemlich genau die Werte
    herausfiltern, die ich auch tatsächlich erwarte und für Werte, die
    nicht erwünscht sind, eine Fehlermeldung herausgeben?

    das hängt wesentlich von Deinem Versionsmanagement ab.
    Wenn Du davon ausgehen kannst, dass Dein Formular immer von deinem Server in der aktuellen Version geladen werden muss, und es keinen Grund dafür gibt, es irgendwo zu speichern, dann würde ich immer auf größtmögliche Sicherheit gehen.

    Das bedeutet, dass nur exakt die Parameter verarbeitet werden, die Du erwartest, keine fehlen darf und keiner zuviel sein darf.

    Vorausgestzt ist natürlich, dass es sich nicht um einen Erstaufruf des Scriptes _ohne_ Paramter handelt...

    Und eine qualifizierte Fehlermeldung solltest Du dem User auch nicht geben, sondern ihn ein wenig an der Nase herumführen: Bitte nochmal versuchen...

    Und selber solltest Du ein Log schreiben, dass Dir hilft, Dauerstörer ausfindig machen zu können.

    LG
    Chris

    1. Hallo Chris,

      Das bedeutet, dass nur exakt die Parameter verarbeitet werden, die Du erwartest, keine fehlen darf und keiner zuviel sein darf.

      ja, das mache ich sogar peinlich genau.

      Und eine qualifizierte Fehlermeldung solltest Du dem User auch nicht geben, sondern ihn ein wenig an der Nase herumführen: Bitte nochmal versuchen...

      naja, ich teile ihm schon mit, wenn er zum Beispiel ein notwendiges
      Feld leer gelassen hat...

      Und selber solltest Du ein Log schreiben, dass Dir hilft, Dauerstörer ausfindig machen zu können.

      und das mache ich ekelhafter Weise auch ziemlich genau :-)

      Ich danke dir und wünsche noch einen schönen Sonntag.

      Greez,
      opi

      --
      Selfcode: ie:( fl:( br:^ va:) ls:] fo:) rl:( n4:? ss:| de:] ch:? mo:|
  3. Hallo!

    Mein Gedanke hierbei ist, dass wenn ich diese Werte nicht filter,
    sie dann in meinem Skript rumlungern. Wenn ich aber sowas wie einen
    Filter einbaue, ich dabei eine riesen Liste pflegen muss, da die
    Funktion ja global genutzt wird.

    Die Frage ist, was mit den unerwarteten Parametern (oder wie auch immer Cheatah das nennt...) passiert. Z.B. kommt auch heute noch der größte Teil der aktuellen Sicherheitslücken in PHP-Anwendungen dadurch, dass solche unerwarteten Parameter automatisch als PHP-Variablen initialisiert werden - solange register_globals verwendet wird (obwohl da schon wirklich viele Jahrer lang von abgeraten wird). Es ist immer dasselbe - es werden absichtlich globale Variablen, die nicht im Script initalisiert worden sind unerwarted auf diesem Weg übergeben.

    Wenn man aber register_globals abschaltet, und nur noch über die superglobalen Arrays ($_GET, $_POST...) auf die übertragenen Daten zugreift, muss man sich keine Sorgen machen - oder zumindest deutlich weniger (siehe "register_globals is not evil" unten).

    Siehe auch:
    PHP-Manual -> Sicherheit -> Verwendung von Register Globals
    Stefan Esser: register_globals is not evil
    Talk (Stefan Esser): "Grundlagen der sicheren PHP Programmierung - Teil 1" (pdf, 131kb)

    Grüße
    Andreas

    --
    SELFHTML Feature Artikel: http://aktuell.de.selfhtml.org/artikel/
    1. Hi,

      da habe ich die letzte Woche doch tatsächlich eine Script-Chaos-Sammlung überarbweiten müssen, die zwar mit regsigter_globals = off arbeitet, aber dafür

      include('config.inc.php');

      extract($_GET);
      extract($_POST);
      extract($_REQUEST);
      extract($_SERVER);

      in jedem Script vorne drinstehen hat.

      Die Reihenfolge gibt zusätzlich zur Sinnlosigkeit des Codes an sich zu denken.

      LG
      Chris

      1. Hallo!

        include('config.inc.php');

        extract($_GET);
        extract($_POST);
        extract($_REQUEST);
        extract($_SERVER);

        in jedem Script vorne drinstehen hat.

        na herzlichen Glückwunsch ;-)

        Die Reihenfolge gibt zusätzlich zur Sinnlosigkeit des Codes an sich zu denken.

        Naja, die Reihenfolge ist bis auf $_REQUEST dieselbe ist wie standardmäßig durch variables_order in der php.ini bei register_globals. Im Endeffekt wirkt es genau so als wären register_globals an - mit allen damit verbundenen Nachteilen...

        Grüße
        Andreas

        --
        SELFHTML Tipps & Tricks: http://aktuell.de.selfhtml.org/tippstricks/
        1. Hi,

          include('config.inc.php');

          extract($_GET);
          extract($_POST);
          extract($_REQUEST);
          extract($_SERVER);

          in jedem Script vorne drinstehen hat.

          na herzlichen Glückwunsch ;-)

          Die Reihenfolge gibt zusätzlich zur Sinnlosigkeit des Codes an sich zu denken.

          Naja, die Reihenfolge ist bis auf $_REQUEST dieselbe ist wie standardmäßig durch variables_order in der php.ini bei register_globals. Im Endeffekt wirkt es genau so als wären register_globals an - mit allen damit verbundenen Nachteilen...

          Nee, es ist schlimmer so.
          Da das include der Voreinstellungen _vor_ dem extract() durchgeführt wird, werden die Voreinstellungen (die eine Sicherheit bieten) durch den Import der Arrays wieder überschrieben.

          Allerdings hat extract() auch zusätzliche Argumente, um dieses ggf. zu vermeiden. Die werden hier aber nicht benutzt.

          LG
          Chris

  4. argumente - wie der name schon sagt. was sind (sinnvolle) argumente? müssen sich diese im kontext bewegen? in der kneipe ist das nicht immer der fall.

    aber computertechnisch gesehen ist es so: ausgabe=funktion(eingabe). nun kann die funktion entscheiden, ob nur argumente erlaubt sind, welche im kontext der funktion stehen oder nicht, d.h. andere werden ignoriert.

    leider tritt aber das schon angesprochene problem mit den global variablen in php auf. dies führt bei schlechter programmierung zu unerwünschten ergebnissen.

    bei sauberer programmierung mit kapselung werden keine globalen variablen benutzt. daher können globale variablen keinen einfluß auf den ablauf nehmen.

  5. Ein kleines Beispiel:

    Aus einem Formular heraus erwarte ich die Werte

    Name=Schroeder&Vorname=Atze

    Nun erhalte ich allerdings noch zusätzlich die Werte wie zum Beispiel

    bla=bla

    Jetzt weiß ich nicht so recht, was ich damit machen soll. Ist das
    vollkommen unwichtig oder sollte ich ziemlich genau die Werte
    herausfiltern, die ich auch tatsächlich erwarte und für Werte, die
    nicht erwünscht sind, eine Fehlermeldung herausgeben?

    Da du mit Perl deine CGI Anwendungen schreibst, sind die Parameter egal.
    Sie sind aber insofern "Sondermüll", dass sie innerhalb des CGI Moduls gespeichert werden. "Sauber" lösen liesse sich das nur, wenn man dem Modul irgendwie mitteilen könnte, welche Parameter man wirklich benötigt. Was zwar einen etwas erhöhten Pflegeaufwand (falls ein Parameter dazu kommt oder umbenannt wird) nach sich zieht. aber vermeiden würde das unnötig Speicher verbraucht wird.

    Bei PHP sieht das unter Umständen aber anders aus, da es Konfigurationen gibt, wo, in deinem Beispiel, automatisch die globale Variabel $bla = 'bla' wird.

    Struppi.