[mySQL] Strings richtig escapen, wie geht ihr vor?

[Frezl]

Hallo allerseits,

ich habe jetzt schon ein Wenig im Forum rumgesucht und einige Threads zum Thema gelesen, aber noch nicht so richtig die Antwort auf meine Frage gefunden: Wie muss ich Strings richtig escapen, damit die Original-Eingaben erhalten bleiben?

Bis jetzt habe ich Eingaben immer mit trim (htmlspecialchars ($string)) gesichert. Das wird auch in vielen Threads empfohlen. Leider wird dadurch der String verändert. Die Ausgabe in HTML sieht zwar aus wie das Original, aber in Wahrheit sind die Zeichen ja durch ihre Entities ersetzt.

Jetzt habe ich mir mysql_real_escape_string ($string) genauer angeschaut. Da weiß ich aber nicht so genau, wie ich die Ausgabe bearbeiten muss, dass die Slashes wieder verschwinden. Langt da strip_slashes ($string)? Bleiben aber immer noch die Slashes in der Datenbank, wo ich mir nicht so sicher bin, ob die mir mal auf irgend eine Weise Probleme bereiten werden.

Gibt es nicht eine Option, dass PHP automatisch alle Strings in Queries maskiert und beim Abrufen wieder demaskiert, sodass ich mich darum gar nicht kümmern muss?

Wie ist euer generelles Vorgehen?

Würde mich über einige Tipps freuen!

Viele Grüße,
Frezl

 

[m0dpad]

Wenn du die Daten in die Datenbank schreibst, escapest du diese mit mysql_real_escape_string($string) oder verwendest prepared statements z.B.. Damit wird der String selbst nicht verändert, wenn du ihn wieder ausliest brauchst du kein strip_tags oder ähnliches.

Wenn du ihn ausgeben möchtest reicht in den meisten Fällen ein htmlspecialchars($string) aus. Wenn du davor noch ein strip_tags() auf den String anwendest, dann ist es für die Benutzer nicht mehr möglich HTML Tags zu schreiben, was eigentlich fast nie sinnvoll ist ?

Beispiel:
<a href="example.com">Test</a> wär dann halt nur noch der Text "Test".

Generell gilt, das du in die Datenbank immer die Rohdaten reinschreibst und erst bei der Ausgabe die entsprechenden HTML - Entitäten umwandelst. Es sei denn, es sind wirklich performance intensive Operationen, dann können diese auch ausgeführt werden bevor die Daten in die Datenbank geschrieben werden.

 

[Frezl]

Vielen Dank für die schnelle und ausführliche Antwort.

Bis jetzt bin ich immer nach der Philosophie verfahren, User-Input sofort zu entschärfen, bevor ich diesen auf irgend eine Weise weiterbearbeite. Verstehe ich das richtig, dass ich diesen Schritt bei Verwendung von mysql_real_escape_string () erst dann ausführe, wenn ich die Daten aus der DB abgerufen habe und wieder ausgeben will?

Viele Grüße,
Frezl

// EDIT:
Ich hab mir jetzt mal ein Wenig Know How zu den Prepared Statements angelesen (http://www.sjmp.de/wp-content/uploa...-Statements-IT-Grundschutz-hakin9-03-2011.pdf) und muss sagen, dass mich die Möglichkeit schwer begeistert! Dazu aber eine Frage: Kann ich jetzt ganz auf das Escapen der Eingaben verzichten?

 

[CPoly]

Du wirfst hier Sachen etwas durcheinander. Es geht um folgende zwei völlig unterschiedliche Dinge:

1. Wenn du eine Benutzereingabe in einer Datenbankabfrage verwendest, musst du diese Sichern. Z.B. mit mysql_real_escape_string oder viel besser mit prepared statements. Das musst du auf jeden Fall beim Eintragen machen. Die Daten stehen danach exakt so in der Datenbank, wie sie der Nutzer eingegeben hat (Sofern es sich um ein INSERT gehandelt hat. Bei einem SELECT werden die Daten eben exakt so verwendet, wie der Nutzer sie eingegeben hat). Das escapen verändert die Daten nicht, sondern ermöglicht nur das Eintragen in die Datenbank.

2. Wenn du Benutzereingaben in eine HTML Seite einfügst (Gästebucheinträge, Suchanfrage (Ihre Suche nach "Foo" ergab...), etc.) dann musst du verhindern, dass HTML (speziell JavaScript) durch den Nutzer in die Seite eingefügt werden kann. Dazu benutzt du bei der Ausgabe auf der Seite z.B. htmlspecialchars oder htmlentities.


Jetzt lässt sich 2. noch spezialisierst betrachten. Es könnte ja sein, dass du Nutzereingaben in einem JavaScript verwendet oder auch in deinem CSS oder in HTML Attributen. Die musst du dann alle nochmal anders escapen. Aber diese Anwendungsfälle sind eher selten.

Edit:
Es bleibt auch dir überlassen, ob du die Daten für 2. schon vor dem Eintragen in die Datenbank sichern willst. Das macht man aber eher ungern, weil du deinen Daten damit schon den Stempel "HTML" aufdrückst.

 

[Frezl]

Danke für deine Atwort,

zu

Das escapen verändert die Daten nicht, sondern ermöglicht nur das Eintragen in die Datenbank.

hab ich jetzt gemerkt, dass bei mir magic_quotes an war, daher hat das Escapen die Daten geändert. Nachdem ich das jetzt weiß, hat sich dieses Problem schon mal gelöst

Außerdem vielen Dank, dass du mir die übliche Vorgehensweise noch mal genauer erklärt hast!

Werd mich weiter mit den prepared statements befassen, das scheint mir ne gute Weiterentwicklung im mySQL zu sein.

Viele Grüße,
Frezl

 

[CPoly]

hab ich jetzt gemerkt, dass bei mir magic_quotes an war, daher hat das Escapen die Daten geändert.

Ich würde eher umgekehrt sagen. magic_quotes hat die Daten verändert (deshalb unbedingt abschalten) und das Escapen hat die veränderten Daten wie gewünscht eingetragen. Dafür das magic_quotes so einen Mist macht (ist ja nicht umsonst deprecated) kann ja mysql_real_escape_string nichts.

Warning
This feature has been DEPRECATED as of PHP 5.3.0. Relying on this feature is highly discouraged.

 

[Frezl]

Naja. Wenn ich ohne mysql_real_escape_string () arbeite, landen die Daten so in der Datenbank, wie ich sie abgesendet hab. Wenn ich es verwende, hab ich vor allen Sonderzeichen Slashes stehen. Würde also schon behaupten, dass die Funktion "schuld" ist, weil sie Strings escaped, die danach mit magic_quotes sowieso noch Mal escaped werden, was dazu führt, dass die Slashes selbst escaped werden und daher als sichtbare Zeichen im String landen...

Hab jetzt ne eigene escape-Funktion geschrieben, die vorher schaut, ob magic_quotes an ist...

Grüße,
Fred

 

[chibisuke]

achtung, magic quotes kann gegebenfalls auch sybase Escaping gemacht haben.

in diesem fall werden hochkomma verdoppelt anstatt mit backslashes versehen.