Haspin: Kommentarformular in die Datenbank *Sicherheit*

Hallo liebe SELFHTML´ler,
ich möchte gerne gerne Kommentare zu meinen Artikeln erlauben. Ich habe aber ein paar bedenken bezüglich der Sicherheit, da ich die Daten aus dem Textfeld in die Datenbank spiele möchte ich sicherstellen, das mir da nichts durchrutscht.
Irgendwie finde ich den real_escape_sting als unzureichend um Textfelder per post in die Datenbank zu schieben.
Was meint ihr?

Danke Haspin

  1. Versuchs mal mit strip_tags

    1. Moin

      Versuchs mal mit strip_tags

      Das gehört in die Ausgabe eines Strings, nicht in die Abspeicherung dieses in die Datenbank.

      Gruß Bobby

      --
      -> Für jedes Problem gibt es eine Lösung, die einfach, sauber und falsch ist! <-
      ### Henry L. Mencken ###
      -> Nicht das Problem macht die Schwierigkeiten, sondern unsere Sichtweise! <-
      ## Viktor Frankl ###
      ie:{ br:> fl:{ va:} ls:< fo:) rl:( n4:( de:> ss:) ch:? js:( mo:} sh:) zu:)
  2. Hi,

    Irgendwie finde ich den real_escape_sting als unzureichend um Textfelder per post in die Datenbank zu schieben.

    Unzureichend hinsichtlich was?

    Was meint ihr?

    Ahnung besorgen: http://aktuell.de.selfhtml.org/artikel/review/kontextwechsel/

    MfG ChrisB

    --
    Light travels faster than sound - that's why most people appear bright until you hear them speak.
  3. also ich kann noch meinen senf dazu geben ...

    mysql_real_escape_string(htmlentities(striptags($deintext)));

    hat bei mir eigentlich in jedem Kontaktformular geholfen ...

    --------------

    IT & PR - zinsnavigator.de
    janfeddersen _at_ dunkelnetz _dot_ de
    Kredit Umschuldung ? Wir helfen !

    1. Hi Jan,

      mysql_real_escape_string(htmlentities(striptags($deintext)));

      warum willst Du denn nicht einfach das speichern, was die Leute auch schreiben?

      Viele Grüße,
      der Bademeister

      1. hmmm ... vielleicht Wegen Spam und vielleicht noch viel eher ... weil es immer wieder lücken in diversen Browsern gibt die durch z.b. Overflow's in bildern ausgelöst werden. oder Javascript attacken .. wenn ich diese nicht Vorher herausfilter .. hab ich ganz schnell eine Website die Viren oder ähnliches verbreitet .... Vielleicht hast du es mitbekommen das früher in einigen gästebüchern HTML code erlaubt war ... damit wurden wiederum bilder eingebunden die overflows in browsern ausgelöst haben und damit wiederum Trojandownloader auf dem rechner haben loslegen lassen ....

        okay lange rede kurzer sinn ... um meine site sauber zu halten ...

        --------------

        IT & PR - zinsnavigator.de
        janfeddersen _at_ dunkelnetz _dot_ de
        Kredit Umschuldung ? Wir helfen !

        1. Moin

          hmmm ... vielleicht Wegen Spam und vielleicht noch viel eher ... weil es immer wieder lücken in diversen Browsern gibt die durch z.b. Overflow's in bildern ausgelöst werden. oder Javascript attacken .. wenn ich diese nicht Vorher herausfilter .. hab ich ganz schnell eine Website die Viren oder ähnliches verbreitet .... Vielleicht hast du es mitbekommen das früher in einigen gästebüchern HTML code erlaubt war ... damit wurden wiederum bilder eingebunden die overflows in browsern ausgelöst haben und damit wiederum Trojandownloader auf dem rechner haben loslegen lassen ....

          okay lange rede kurzer sinn ... um meine site sauber zu halten ...

          Quatsch ist das. Behandle die Daten bei der Ausgabe mit deinen erwähnten Funktionen. Zum Schreiben in die Datenbank genügt die Werte in Hoichkomma zu schreiben und mit der Funktion mysql_real_escape_string() bzw mysqli_real_escape_string() zu behandeln. Nochmal. PHP-Funktionen wie htmlentities(), oder strip_tags() o.ä. haben bei der Abspeicherung nichts zu suchen!

          Gruß Bobby

          --
          -> Für jedes Problem gibt es eine Lösung, die einfach, sauber und falsch ist! <-
          ### Henry L. Mencken ###
          -> Nicht das Problem macht die Schwierigkeiten, sondern unsere Sichtweise! <-
          ## Viktor Frankl ###
          ie:{ br:> fl:{ va:} ls:< fo:) rl:( n4:( de:> ss:) ch:? js:( mo:} sh:) zu:)
        2. ... Vielleicht hast du es mitbekommen das früher in einigen gästebüchern HTML code erlaubt war ...

          Ja. "Code" ist zum Beispiel auch in diesem Forum erlaubt. Hier darf ich schreiben

          <p>Hallo Jan</p>

          und Du kriegst den HTML-Code (nicht das interpretierte Ergebnis, sondern den Code) auch zu sehen. Stell Dir mal vor, hier würde nur die strip_tags()-Rückgabe meines Postings gespeichert...

          Viele Grüße,
          der Bademeister

          1. sorry, Ich versteh eure Einwände, wenn Ihr Code mit wegspeichern wollt. Ich ging von einem Text Kommentar aus.

            Gruß

            ps. vor dem DB schreiben die sachen zu säubern hat den Vorteil das eventuelle javascripts / html einschläusungen einem tools wie PhpMyAdmin nicht auser gefecht setzen (ich weiß der ist mitlerweile auch etwas mehr gesichert).

            1. Mahlzeit Jan Feddersen,

              ps. vor dem DB schreiben die sachen zu säubern hat den Vorteil das eventuelle javascripts / html einschläusungen einem tools wie PhpMyAdmin nicht auser gefecht setzen

              Wenn "so etwas" ein (von Dritten entwickeltes) Tool "außer Gefecht setzt", dann ist dieses Tool schlampig programmiert worden.

              MfG,
              EKKi

              --
              sh:( fo:| ch:? rl:( br:> n4:~ ie:% mo:} va:) de:] zu:) fl:{ ss:) ls:& js:|
            2. Moin

              sorry, Ich versteh eure Einwände, wenn Ihr Code mit wegspeichern wollt. Ich ging von einem Text Kommentar aus.

              Auch dann sind die Daten kontextspezifisch zu behandeln. Die Daten kommen in die DB wie sie vom benutzer geschrieben wurden und werden erst bei der Ausgabe entsprechend behandelt. Da gibt es auch keine Zwischenwege. Dieses Konzept sollte _immer_ beibehalten werden.

              ps. vor dem DB schreiben die sachen zu säubern hat den Vorteil das eventuelle javascripts / html einschläusungen einem tools wie PhpMyAdmin nicht auser gefecht setzen (ich weiß der ist mitlerweile auch etwas mehr gesichert).

              Auch das ist Quatsch. Wenn solch ein Tool sich von "Einschleussungen" (richtig: XSS und MySQL-Injection) beeindrucken lässt ist eben die Kontextspezifische Behandlung in diesem Tool nicht beachtet und somit SCHROTT ™

              Gruß Bobby

              --
              -> Für jedes Problem gibt es eine Lösung, die einfach, sauber und falsch ist! <-
              ### Henry L. Mencken ###
              -> Nicht das Problem macht die Schwierigkeiten, sondern unsere Sichtweise! <-
              ## Viktor Frankl ###
              ie:{ br:> fl:{ va:} ls:< fo:) rl:( n4:( de:> ss:) ch:? js:( mo:} sh:) zu:)
              1. Auch dann sind die Daten kontextspezifisch zu behandeln. Die Daten kommen in die DB wie sie vom benutzer geschrieben wurden und werden erst bei der Ausgabe entsprechend behandelt. Da gibt es auch keine Zwischenwege. Dieses Konzept sollte _immer_ beibehalten werden.

                Ich liebe _Nachdrücklichkeit_

                Es schadet nichts, die anwendungstauglichkeit von Daten zu prüfen, bevor man sie zur späteren Anwendung speichert. Es sei denn du spezialisiert dich im Horten syntaktisch invalider Daten in einem emailfeld (z.B.).

                mfg Beat

                --
                ><o(((°>           ><o(((°>
                   <°)))o><                     ><o(((°>o
                Der Valigator leibt diese Fische
                1. Hi!

                  Auch dann sind die Daten kontextspezifisch zu behandeln. Die Daten kommen in die DB wie sie vom benutzer geschrieben wurden und werden erst bei der Ausgabe entsprechend behandelt. Da gibt es auch keine Zwischenwege. Dieses Konzept sollte _immer_ beibehalten werden.

                  Regeln und Grundsätze sollten nicht als Ruhekissen verwendet werden, nicht mehr nachdenken zu müssen, sondern eher als Entscheidungshilfe.

                  Es schadet nichts, die anwendungstauglichkeit von Daten zu prüfen, bevor man sie zur späteren Anwendung speichert. Es sei denn du spezialisiert dich im Horten syntaktisch invalider Daten in einem emailfeld (z.B.).

                  Hier gilt es die fachlichen Anforderungen von denen der Ausgabemedien zu unterscheiden. Im Ausgabeemedium nützen mir valide Daten nichts, wenn sie inhaltlich nicht passen. Ungünstig ist es aber auch, wenn sie zwar valide aber inhaltlich verstümmelt sind. Oder anders: Spam bleibt auch im validen Zustand Spam. Kaputte Nutzdaten sind auch sch..lecht.

                  Lo!

            3. Hi!

              Wenn ich mich auch noch reinhängen darf ...

              sorry, Ich versteh eure Einwände, wenn Ihr Code mit wegspeichern wollt. Ich ging von einem Text Kommentar aus.

              Ein Bereinigen der Eingabedaten muss erfolgen, wenn es eine "Transportsicherung" zu entfernen gibt. Das ist bei PHP normalerweise nicht notwendig, die Daten kommen im Rohformat (außer wenn Magic Quotes eingeschaltet sind).

              Eine Prüfung auf den Inhalt sollte aus fachlichen Erwägungen erfolgen. Wenn für einen Wert eine Zahl erforderlich ist, ist eine Zahlenprüfung angebracht. Wenn du dich entscheidest, keinen (HTML-, Javscript-, sonstwelchen) Code haben zu wollen, dann aus inhaltlichen und fachlichen Gründen, und nicht aus sicherheitstechnischen für irgendwelche Ausgabemedien. Das Ausgabemedium sollte hier also noch keine Rolle spielen, denn wenn man schön modular programmiert, darf es die Eingabedatenverarbeitung nicht interessieren, wohin später irgendwann mal was ausgegeben wird. Dies können unterschiedliche Medien mit verschiedenen Bedingungen sein. Sich am Eingang bereits für einen Ausgang vorzubereiten, bedeutet, die ganze Zeit Ballast rumzuschleppen, der dann am Ausgang gar nicht oder ganz andere gebraucht wird. Die Daten sollten also während der Verarbeitung immer in Rohfom bleiben.

              Für kleine Projekte hört sich das vielleicht aufwendig an, modular zu programmieren, weil man oft die komplette Verarbeitung recht übersichtlich beieinander stehen hat. Doch vielleicht wächst das Projekt später mal oder man will ein anderes größeres aufsetzen. Dann tut man gut daran, gleich vorausschauend geplant zu haben (was nicht heißt, vorgreifend zu programmieren) beziehungsweise schon im Kleinen Erfahrungen mit der Separierung nach Aufgaben gesammelt zu haben. Die Modulierung muss nicht zwingend mit syntaktischen Mitteln erfolgen (Funktionen, OOP), für's kleine Projektchen kann durchaus "geradeaus" programmiert werden, aber eben nach Teilvorgang getrennt. Schon mit Kommentaren kann man das nachvollziehbar gestalten.

              Die Programmlogik zur Ausgabe (egal ob Datenbank, HTML und anderswohin) sollte am besten wissen, wie die Daten gefahrlos ausgegeben werden können. Es sollte allein ihre Aufgabe sein, die ihr übergebenen Rohformatdaten jeweils passend aufzubereiten.

              ps. vor dem DB schreiben die sachen zu säubern hat den Vorteil das eventuelle javascripts / html einschläusungen einem tools wie PhpMyAdmin nicht auser gefecht setzen (ich weiß der ist mitlerweile auch etwas mehr gesichert).

              Welche aktuellen Versionen von phpMyAdmin sind denn davon betroffen? Oder anders gefragt: wie lange liegen diese Versäumnisse mittlerweile zurück?

              Lo!

            4. sorry, Ich versteh eure Einwände, wenn Ihr Code mit wegspeichern wollt. Ich ging von einem Text Kommentar aus.

              Ich habe vor ein paar Wochen folgendes erlebt (eine wirklich wahre Geschichte):

              Ein User schreibt in ein Forum (oder eher Gaestebuch, wie auch immer) sinngemaess: "Hey Leute, schaut Euch das mal an: <www.example.org/tolleseite> Echt grossartig!"

              Und alle anderen schauen etwas ratlos, als sie lesen: "Hey Leute, schaut Euch das mal an: Echt grossartig!"

              Grund - klar - strip_tags(). (Dass er es genau so geschrieben hat, habe ich nicht nur geraten, sondern mit ihm hinterher geklaert, ich kenne ihn gut.)

              Er haette den Link natuerlich nicht in spitze Klammern setzen muessen, aber er hat es nun mal getan. Und strip_tags() interessiert es nicht, ob der Name des vermeindlichen Tags der eines existierenden HTML-Elementes ist.

              Lass doch die Leute schreiben, was sie wollen. Es gibt keinen guten Grund, festzulegen, dass in einem "Textkommentar", wie Du es genannt hast, keine spitzen Klammern vorkommen koennen.

              ich weiß der [PHPMyAdmin] ist mitlerweile auch etwas mehr gesichert.

              Wann war er das denn nicht?

              Viele Gruesse,
              der Bademeister

        3. Mahlzeit Jan Feddersen,

          hmmm ... vielleicht Wegen Spam und vielleicht noch viel eher

          Was hat Spam damit zu tun?

          ... weil es immer wieder lücken in diversen Browsern gibt die durch z.b. Overflow's in bildern ausgelöst werden. oder Javascript attacken

          Wie sollten diese zum Tragen kommen, wenn Du an genau der richtigen Stelle (nämlich bei der *Ausgabe* der in der Datenbank gespeicherten Inhalte) die für diesen Kontextwechsel geeigneten Funktionen benutzt?

          .. wenn ich diese nicht Vorher herausfilter .. hab ich ganz schnell eine Website die Viren oder ähnliches verbreitet ....

          Und wenn Du nun Dinge herausfilterst, die vom Benutzer gewollt eingegeben wurden (und die auch absolut problemlos wären und keinerlei Fehler verursachen würden)? Nur weil Du nicht in der Lage bist, diese Benutzereingaben gezielt an den richtigen Stellen in den richtigen Kontext zu bringen? Ob Deine Benutzer das gut finden?

          Vielleicht hast du es mitbekommen das früher in einigen gästebüchern HTML code erlaubt war ... damit wurden wiederum bilder eingebunden die overflows in browsern ausgelöst haben und damit wiederum Trojandownloader auf dem rechner haben loslegen lassen ....

          Ich habe nur mitbekommen, dass es damals™ Leute gab, die keine Ahnung hatten von dem was sie tun und deshalb nicht darüber nachdachten, was wann wie und warum geschieht und deshalb einfachste Grundregeln der Datenverarbeitung missachteten oder aber - im anderen Extremfall - mit absolut ungeeigneten Maßnahmen vorschnell und unüberlegt zu blindem Aktionismus neigten ... und - oh Wunder! - es gibt diese Leute auch heute noch.

          okay lange rede kurzer sinn ... um meine site sauber zu halten ...

          Das Argument ist Blödsinn - Du hältst damit nicht Deine "site" sauber, sondern Du verstümmelst damit Benutzereingaben (ggf.) sinnentstellend.

          MfG,
          EKKi

          --
          sh:( fo:| ch:? rl:( br:> n4:~ ie:% mo:} va:) de:] zu:) fl:{ ss:) ls:& js:|
        4. hmmm ... vielleicht Wegen Spam

          Spam kannst du durch striptags nicht begegnen.
          Spam ist delikater und braucht andere Ansätze.

          und vielleicht noch viel eher ... weil es immer wieder lücken in diversen Browsern gibt die durch z.b. Overflow's in bildern ausgelöst werden.

          Dann bräuchten wir ein Verbot für
          Content-type: img/jpg
          etc.

          oder Javascript attacken .. wenn ich diese nicht Vorher herausfilter ..

          Warum vorher? Du hast im richtigen Context zu Filtern, also bei der HTML Ausgabe an den Client.

          ...hab ich ganz schnell eine Website die Viren oder ähnliches verbreitet

          Die kannst du auch mit striptags erzeugen, indem du den Sourcecode zu einem trojaner publizierst

          .... Vielleicht hast du es mitbekommen das früher in einigen gästebüchern HTML code erlaubt war ... damit wurden wiederum bilder eingebunden die overflows in browsern ausgelöst haben und damit wiederum Trojandownloader auf dem rechner haben loslegen lassen ....

          HTML Code erlauben ist eine Frage der Kontrolle. BBCode und Varianten machen es möglich.
          Striptags ist schon deshalb unfreundlich, weil es mir und anderen verbietet, überhaupt über HTML zu diskutieren, was ich auf einem durschnittlichen Niveau gerne tue.

          okay lange rede kurzer sinn ... um meine site sauber zu halten ...

          Solltest du kontextspezifisch Daten behandeln.

          Siehe Beispiel im Anhang. ;)))

          mfg Beat

          --
                           /|
            <°)))o><   __ / |    /|
                      /__\ _|___/ |     ><o(((°>
                     OvVVvO    __ |        ><o(((°>
          <°)))o><  /v    v\/  |
           <°)))o>< ^    ^/_/_         ><o(((°>
                     ^^^^/___/
                      ----            ><o(((°>
          ><o(((°>           ><o(((°>
             <°)))o><                     ><o(((°>o
          Der Valigator leibt diese Fische
    2. Moin!

      also ich kann noch meinen senf dazu geben ...

      mysql_real_escape_string(htmlentities(striptags($deintext)));

      hat bei mir eigentlich in jedem Kontaktformular geholfen ...


      IT & PR - zinsnavigator.de
      janfeddersen _at_ dunkelnetz _dot_ de
      Kredit Umschuldung ? Wir helfen !

      Deine Postings erwecken bei mir den Eindruck, dir geht es eher nur darum, etwas gepostet zu haben, um den Werbelink zu legitimieren, den du außerdem in dein Posting schreibst.

      Ich möchte dich bitten, in Zukunft deutlich zurückhaltender zu verlinken. Dazu zählt das Weglassen von Werbebotschaften und einschlägigen langen URLs. Also des gesamten derzeitigen Links.

      Das Verlinken von Projekten, an denen man teilnimmt oder die man verantwortlich betreibt - auch wenn man daraus wirtschaftliche Vorteile zieht - ist solange in Ordnung, wie es nicht den Eindruck vermeidbarer Werbung erweckt. Das gesamte Projekt SELFHTML ist nahezu werbefrei, weil es von unserer ehrenamtlichen Arbeitskraft und dem Hosting-Sponsoring von NTT Europe Online betrieben wird - und es soll bitte auch so bleiben.

      Mit dem schlichten Verlinken der Domain dürftest du genug Google-Pagerank abbekommen.

      Mit freundlichen Grüßen
      Sven Rautenberg
      1. Vorsitzender SELFHTML e.V.

      1. Sorry kommt soweit nichtmehr vor.

  4. Mahlzeit Haspin,

    Ich habe aber ein paar bedenken bezüglich der Sicherheit, da ich die Daten aus dem Textfeld in die Datenbank spiele möchte ich sicherstellen, das mir da nichts durchrutscht.

    Was verstehst Du unter "nichts durchrutscht"?

    Irgendwie finde ich den real_escape_sting als unzureichend um Textfelder per post in die Datenbank zu schieben.

    Warum? Kannst Du außer einem "Bauchgefühl" noch irgendwelche nachvollziehbaren Gründe nennen?

    Was meint ihr?

    Speichere das, was die Benutzer eingegeben haben, in der Datenbank. Nutze dabei entsprechende Funktionen (wie die von Dir erwähnte mysql_real_escape_string()), damit beim Kontextwechsel Formularinhalt -> SQL alles glatt läuft.

    Behandle den in der Datenbank gespeicherten Inhalt bei der Ausgabe (also beim Kontextwechsel Datenbank -> HTML) mit entsprechenden Funktionen ... vorher kannst Du natürlich gerne alle evtl. vorhandenen Tags entfernen - beachte aber den Wortlaut der Beschreibung: "Diese Funktion *versucht* [...]"!

    MfG,
    EKKi

    --
    sh:( fo:| ch:? rl:( br:> n4:~ ie:% mo:} va:) de:] zu:) fl:{ ss:) ls:& js:|