[Erledigt] htmlspecialchars vor Speicherung in DB?

malungo · 30.11.2008, 20:43

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&uuml;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

Manko10 · 30.11.2008, 20:46

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.

nikosch · 30.11.2008, 20:48

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

Manko10 · 30.11.2008, 20:51

Außerdem verbraucht eine unkodierte Speicherung weniger Platz. & ist nunmal einige Zeichen kürzer als &

David · 30.11.2008, 21:00

Zitat:

Zitat von malungo

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.

malungo · 30.11.2008, 21:14

ok, vielen Dank!

Ich glaube dann speichere ich die Daten ohne htmlspecialchars!!

ein mysql_real_escape_string reicht ja gegen SQL Injection, oder?!

nikosch · 30.11.2008, 21:33

Solange die Zuweisung in ' ' erfolgt.

David · 30.11.2008, 21:53

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.

David · 30.11.2008, 22:00

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

nikosch · 30.11.2008, 22:00

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..

Themen-Optionen
Druckbare Version zeigen Jemanden per E-Mail auf dieses Thema hinweisen
Thema bewerten
Thema bewerten:

30.11.2008, 20:43
malungo Benutzer Registriert seit: 16.10.2008 Beiträge: 41	[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


Mister Ad PHP Code Flüsterer Registriert seit: 21.08.2005 Beiträge: 4682 PHP-Kenntnisse: Fortgeschritten

30.11.2008, 20:46
Manko10 Supermoderator HD Registriert seit: 16.03.2008 Beiträge: 8.709 PHP-Kenntnisse: Fortgeschritten	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 Advent Calendar series “24 Outstanding ZSH Gems”

30.11.2008, 20:48
nikosch moderatives Dielektrikum Registriert seit: 21.05.2008 Beiträge: 35.988 PHP-Kenntnisse: Fortgeschritten	Meine Philosophie: Daten so einfach wie möglich speichern. Hält Dir später alle Möglichkeiten offen: alternative Ausgabeformate, unkomplizierte Datenbanksuche... __________________ -- One pixel is still too big. Please make it smaller. ASAP. Initiative Mittelstand. Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers. --

30.11.2008, 20:51
Manko10 Supermoderator HD Registriert seit: 16.03.2008 Beiträge: 8.709 PHP-Kenntnisse: Fortgeschritten	Außerdem verbraucht eine unkodierte Speicherung weniger Platz. & ist nunmal einige Zeichen kürzer als & __________________ Refining Linux Advent Calendar series “24 Outstanding ZSH Gems”

30.11.2008, 21:14
malungo Benutzer Registriert seit: 16.10.2008 Beiträge: 41	ok, vielen Dank! Ich glaube dann speichere ich die Daten ohne htmlspecialchars!! ein mysql_real_escape_string reicht ja gegen SQL Injection, oder?!

30.11.2008, 21:33
nikosch moderatives Dielektrikum Registriert seit: 21.05.2008 Beiträge: 35.988 PHP-Kenntnisse: Fortgeschritten	Solange die Zuweisung in ' ' erfolgt. __________________ -- One pixel is still too big. Please make it smaller. ASAP. Initiative Mittelstand. Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers. --

30.11.2008, 21:53
David Erfahrener Benutzer Registriert seit: 05.09.2007 Beiträge: 5.044	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.

30.11.2008, 22:00
David Erfahrener Benutzer Registriert seit: 05.09.2007 Beiträge: 5.044	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