Ankündigung

Einklappen
Keine Ankündigung bisher.

[Erledigt] htmlspecialchars vor Speicherung in DB?

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • [Erledigt] htmlspecialchars vor Speicherung in DB?

    Hallo Zusammen!

    Ich entwickle gerade eine einfache Benutzerregistrierung.
    Das sieht folgendermaßen aus:
    Wenn der User das Formular abschickt und ein Feld vergessen hat werden natürlich die schon eingegebenen Felder mit den Eingaben befüllt.

    Die Prüfung sieht so aus:
    PHP-Code:
        /* Name */
        
    if (!empty($_POST['surname'])) {
          
    $values['surname'] = htmlspecialchars(trim($_POST['surname']));
          if (!
    preg_match("/^[a-zA-ZäüößÄÜÖ -]*$/"$_POST['surname'])) {
            
    $errors['surname'] = "Ungültige Zeichen im Namen";
          }
        } else {
          
    $errors['surname'] = "Geben Sie einen Namen ein";
        } 
    später schreibe ich dann $values['surname'] in die DB.
    Natürlich bereinige ich die Variable im SQL String mit mysql_reals_escape ...

    Nun wollt ich mal fragen ob ich später evtl. Probleme bekomme wenn ich den htmlspecialchars string in die DB speichere, oder sollte ich ihn lieber ohne htmlspecialchars speichern, und die Funktion immer dann verwenden, wenn ich die Eingaben ausgeben. Cross Site Scripting will ich dadurch vermeiden.

    Beim Kennwort z.B. bekomme ich hier schon Probleme wenn ich den htmlspecialchars string in die DB speichere...

    Danke für Eure Anregungen.

    Malungo


  • #2
    Hallo,

    auf jeden Fall ohne htmlspecialchars() speichern. Anwenden kann man es bei Bedarf später immer noch.
    Aber über SQL-Injections solltest du dich auf jeden Fall informieren.
    Refining Linux: “Performing Push Backups – Part 1: rdiff-backup

    Kommentar


    • #3
      Meine Philosophie: Daten so einfach wie möglich speichern. Hält Dir später alle Möglichkeiten offen: alternative Ausgabeformate, unkomplizierte Datenbanksuche...
      --

      „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
      Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“


      --

      Kommentar


      • #4
        Außerdem verbraucht eine unkodierte Speicherung weniger Platz. & ist nunmal einige Zeichen kürzer als &
        Refining Linux: “Performing Push Backups – Part 1: rdiff-backup

        Kommentar


        • #5
          Zitat von malungo Beitrag anzeigen
          Beim Kennwort z.B. bekomme ich hier schon Probleme wenn ich den htmlspecialchars string in die DB speichere...
          Nein, Du müsstest nur beim Vergleich auch vorher htmlspecialchars() anwenden. Aber... zeigst Du das Passwort in der Regel oder auch nur jemals in HTML an? Das bringt also nichts.

          Der Vorteil, die bereits mit htmlspecialchars() vorbereiteten Daten in der Datenbank zu speichern, ist, dass Du Dir eben den ständigen Aufruf der Funktion beim Ausgeben (als HTML) sparst (Dir oder besser gesagt dem Server).
          Der Nachteil (zusätzlich zu dem schon geschriebenen) ist, dass Du die Verantwortlichkeit verlagerst, aus dem Sichtfeld. Die Ausgabe muss HTML-sicher sein. Aber das siehst Du nicht mehr, weil Du Dich schon bei der Eingabe darum kümmerst. Du musst Dich bei der Ausgabe also auf etwas verlassen, dass Du nicht mehr auf einen Blick siehst. Das würde ich nicht ohne Not und dann vermutlich auch nicht für jedes einzelne Feld machen wollen.

          Kommentar


          • #6
            ok, vielen Dank!

            Ich glaube dann speichere ich die Daten ohne htmlspecialchars!!

            ein mysql_real_escape_string reicht ja gegen SQL Injection, oder?!

            Kommentar


            • #7
              Solange die Zuweisung in ' ' erfolgt.
              --

              „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
              Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“


              --

              Kommentar


              • #8
                Ich habe neulich einen Artikel gelesen, dass das nicht unter allen Umständen ausreicht. Aber das war schon etwas exotisch, da muss einiges zusammenkommen. Wenn ich den Link wiederfinde, wird er nachgereicht.

                Kommentar


                • #9
                  Warum addslashes() nicht ausreicht: Chris Shiflett: addslashes() Versus mysql_real_escape_string()
                  follow-up, warum mysql_real_escape() genauso versagen kann: mysql_real_escape_string() versus Prepared Statements - iBlog - Ilia Alshanetsky
                  Dort ebenfalls verlinkt und interessant: [The Unexpected SQL Injection] Web Security Articles - Web Application Security Consortium

                  Kommentar


                  • #10
                    Sicher im Zusammenhang mit magic quotes.

                    Und - wie gesagt - für erwartete INT Typen reichts auch nicht. Vgl.:

                    PHP-Code:
                    $sql '... WHERE id=' mysql_real_escape ($id) . ' AND pass="' .mysql_real_escape ($pass). '"';

                    $id='1 OR 1=1;' 
                    Oder sowas in der Art..
                    --

                    „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
                    Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“


                    --

                    Kommentar


                    • #11
                      Interessant. Dankeschön!
                      Refining Linux: “Performing Push Backups – Part 1: rdiff-backup

                      Kommentar


                      • #12
                        Es bezieht sich auf die character-set Einstellungen. Zum Beispiel per
                        mysql_query("SET CHARACTER SET 'gbk'", $c);

                        Kommentar


                        • #13
                          Und was lernen wir (wieder) daraus
                          Zitat von http://ilia.ws/archives/103-mysql_real_escape_string-versus-Prepared-Statements.html
                          The solution is to use prepared statements, which are supported by nearly all PHP database extensions with the notable exceptions of MySQL (ext/mysql) and SQLite2 (ext/sqlite). So, to be on the safe side, I'd recommend using the PDO interface to talks with those databases or in the case of MySQL using the newer MySQLi (ext/mysqli) extension. Those interfaces provide prepared statement support, which allows for separation between query structure and the query parameters. It should be noted that while PDO does emulated prepared statements for older versions of MySQL that do not support them natively, emulation is still prone to the same kind of issues demonstrated here and in Chris’ article. Therefore for security reasons you should definitely consider upgrading to a more modern version of MySQL and SQLite (SQLite 3).
                          Amen.

                          Kommentar


                          • #14
                            oje oje...ihr macht mir ja angst!

                            Aber wenn ich Integerwerte schon mal nur in Hochkomma in den sql String stelle kann mir z.B. ID="5 OR 1=1" ja z.B. schon gar nicht passieren!?

                            Desweiteren prüfe ich ja auf gültige Zeichen (regex)...das System dürfte dann ziemlich sicher sein!?

                            und dieser link:
                            mysql_real_escape_string() versus Prepared Statements - iBlog - Ilia Alshanetsky

                            hier ist man doch auch nur anfällig wenn Charset GBK ist, oder verstehe ich das falsch!? ...mit Latin1 dürften keine Probleme auftreten...

                            Prepared Statement scheint mir ein bisschen zu kompliziert...da ich ja nicht mal mit einem DB Objekt in meiner Webanwendung arbeite...
                            Kann ich auch ohne ein sicheres System hinbekommen, oder soll ich lieber gleich komplett umsteigen?

                            btw: Kann es sein, dass Strato und andere Anbieter z.B. gar kein PDO unterstützen? Wenn ja, bräucht ich ja einen Rootserver...

                            Kommentar


                            • #15
                              Zitat von malungo Beitrag anzeigen
                              Aber wenn ich Integerwerte schon mal nur in Hochkomma in den sql String stelle kann mir z.B. ID="5 OR 1=1" ja z.B. schon gar nicht passieren!?
                              in diesem Fall dann natürlich samt mysql_real_escape_string()

                              Zitat von malungo Beitrag anzeigen
                              hier ist man doch auch nur anfällig wenn Charset GBK ist, oder verstehe ich das falsch!? ...mit Latin1 dürften keine Probleme auftreten...
                              GBK hat sich Chris Shiflett als Beispiel rausgesucht. Ob es weitere Kombinationen gibt ...vermutlich.

                              Zitat von malungo Beitrag anzeigen
                              btw: Kann es sein, dass Strato und andere Anbieter z.B. gar kein PDO unterstützen?
                              ja, das ist ein Problem.

                              Kommentar

                              Lädt...
                              X