Chris: Formulareingaben mit strip_tags prüfen?

Hallo ihr,

ist das richtig, dass ich sämtliche Eingaben, die per POST oder GET kommen, mittels strip_tags überprüfen bzw. bereinigen sollte, damit mir niemand schadhaften Code unterjubelt?

Oder kann ich das ab PHP 5.x komplett sein lassen?

Lg
Chris

  1. Hi,

    ist das richtig, dass ich sämtliche Eingaben, die per POST oder GET kommen, mittels strip_tags überprüfen bzw. bereinigen sollte, damit mir niemand schadhaften Code unterjubelt?

    nö.

    Oder kann ich das ab PHP 5.x komplett sein lassen?

    Daten vom Client blind zu vertrauen wird *immer* falsch sein. Es gibt aber nicht per se Gründe, irgendwelche Dinge, die nach HTML aussehen, pauschal wegzuschmeißen. Statt dessen kannst Du dem Grundsatz folgen:

    Wenn Du einen Wert in einen Kontext bringst, musst Du ihn kontextspezifisch kodieren.

    Damit wird, wenn z.B. jemand <script type="text/javascript">evil_function();</script> eingibt, das selbe passieren wie hier im Forum: Der scheinbare Code ist harmloser Text. Beachte obigen Grundsatz bei *jedem* Umgang mit *allen* Daten.

    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. ist das richtig, dass ich sämtliche Eingaben, die per POST oder GET kommen, mittels strip_tags überprüfen bzw. bereinigen sollte, damit mir niemand schadhaften Code unterjubelt?

      nö.
      ...
      Beachte obigen Grundsatz bei *jedem* Umgang mit *allen* Daten.

      Vielen Dank. Ich hatte nur mal gelesen, dass man bei älteren PHP-Versionen zb in ein Formularfeld eingeben konnte

      ';

      Und damit das Script unterbrochen würde, weil er '; dann als PHP-Code ansieht, der anstelle von $_GET['formularfeld'] eingefügt wird. Und nach dem '; könnte dann weiterer, evtl. schädlicher PHP-Code folgen.

      Wenn die Gefahr nicht besteht, ist ja alles bestens, vielen Dank!

      Lg
      Chris

      1. Vielen Dank. Ich hatte nur mal gelesen, dass man bei älteren PHP-Versionen zb in ein Formularfeld eingeben konnte

        ';

        das funktioniert auch bei neueren version noch und nennt sich injection (vornehmlich bekannt durch sql-injections)

        das hängt aber maßgeblich von der einstellung magic_quotes_gpc ab

        umgehen oder manuell escapen lassen sich die hochkommas aber auch durch addslashes

        1. Hello,

          umgehen oder manuell escapen lassen sich die hochkommas aber auch durch addslashes

          Welchen Nutzen kann addslashes() in der Praxis haben?

          Kannst Du mir eine Datenbank nennen, für die addslashes() genau die richtige Vorbehandlung ist, um die resultierenden Daten dann über eine Textschnittstelle übergeben zu dürfen?

          Bei der Übergabe an Dateien oder Datenbanken per Blockbuffer ist es ja irrelevant, da dessen Ausdehnung explizit bekannt ist und er daher gar nicht "ausgepackt" und interpretiert werden muss. Nur bei der impliziten Längensteuerung (durch den übergebenen String selber, durch in ihm enthaltene Steuerzeichen) ist es relevant, weil anderenfalls der Zeichenvorrat für die Nutzdaten eingeschränkt werden müsste.

          Ein harzliches Glückauf

          Tom vom Berg

          --
          Nur selber lernen macht schlau
          http://bergpost.annerschbarrich.de
          1. Welchen Nutzen kann addslashes() in der Praxis haben?

            Kannst Du mir eine Datenbank nennen, für die addslashes() genau die richtige Vorbehandlung ist, um die resultierenden Daten dann über eine Textschnittstelle übergeben zu dürfen?

            addslashes() ist für die übergabe an datenbanken sicher nicht das richtige, da hast du recht - dafür gibts zb mysql_real_escape_string()

            aber man muss ja nicht zwangsläufig mit datenbanken arbeiten, textdatein tuns zb auch - für einfache template-systeme zb eignet sich in manchen fällen eval() mit addslashes()

            1. Hello,

              aber man muss ja nicht zwangsläufig mit datenbanken arbeiten, textdatein tuns zb auch - für einfache template-systeme zb eignet sich in manchen fällen eval() mit addslashes()

              Mmmh, das kann ich im Geiste jetzt nicht nachvollziehen, denn um die Daten in die Textdatei oder eine andere "normale" Datei zu befördern, benötigt man kein addslashes(). Das funktioniert Blockbuffer-orientiert. Dem System ist die Größe des Textstrings explizit bekannt und muss nicht über den Inhalt festgestellt werden. Hier Ist eine strikte Trennung von Daten und Steuerzeichen gewährleistet.

              Wie das nun bei der späteren Verarbeitung und Ausgabe ist, vermag ich aus dem Handgelenk nicht zu beurteilen. Ich würde aber vermuten, dass dort auch kein addslashes() angebracht ist, sondern eher andere Funktionen. Wenn Du also ein praktisches Besipiel (bitte halte es einfach, damit ich es auch verstehe ...) nennen könntest, würde dieses den Thread extrem bereichern ;-)

              Ein harzliches Glückauf

              Tom vom Berg

              --
              Nur selber lernen macht schlau
              http://bergpost.annerschbarrich.de
      2. Hi,

        Beachte obigen Grundsatz bei *jedem* Umgang mit *allen* Daten.

        Vielen Dank. Ich hatte nur mal gelesen, dass man bei älteren PHP-Versionen zb in ein Formularfeld eingeben konnte

        ';

        jau. Wenn Du diesen Wert kontextspezifisch kodierst, wird dann dieses "';" samt folgendem Inhalt des Eingabefeldes in die Datenbank geschrieben (vorausgesetzt, das DB-Layout erlaubt dies an dieser Stelle - ansonsten schmeißt es einen handelsüblichen Fehler zurück).

        Wenn die Gefahr nicht besteht, ist ja alles bestens, vielen Dank!

        Wenn Du den Wert *nicht* kontextspezifisch kodierst, besteht die Gefahr.

        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