htmlspecialchars() vs. mysql_real_escape_string()
johny7
- php
Moin allerseits,
ich will Formulareingaben in eine Datenbank speichern. Weil ich diese Eingaben später in Tabellen ausgeben will, will ich, dass HTML maskiert wird.
Wenn ich nun htmlspecialchars() UND mysql_real_escape_string() verwende, werden Anführungsstriche nicht nur umgewandelt sondern auch noch mit \ escaped. Wie kann ich das verhindern? Oder reicht es für die mysql-Sicherheit aus, wenn ich alle Formularangaben durch htmlspecialchars() laufen lasse? Kann ich dann den anderen Befehl einfach weglassen?
Grüße, JN
Mahlzeit johny7,
ich will Formulareingaben in eine Datenbank speichern.
Dann solltest Du sie *beim Speichern* in der Datenbank mit den dafür vorgesehenen Funktionen kontextgerecht behandeln.
Weil ich diese Eingaben später in Tabellen ausgeben will, will ich, dass HTML maskiert wird.
Dann solltest Du sie *beim Ausgeben* als HTML mit den dafür vorgesehenen Funktionen kontextgerecht behandeln.
Wenn ich nun htmlspecialchars() UND mysql_real_escape_string() verwende, werden Anführungsstriche nicht nur umgewandelt sondern auch noch mit \ escaped. Wie kann ich das verhindern?
Indem Du den Artikel "Kontextwechsel" liest und verstehst.
MfG,
EKKi
Moin allerseits,
Dann solltest Du sie *beim Speichern* in der Datenbank mit den dafür vorgesehenen Funktionen kontextgerecht behandeln.
OK, nun wende ich beim Speichern mysql_real_escape_string() an.
Dann werden alle Anführungszeichen in der Datenbank mit Backslashes gespeichert.
Dann solltest Du sie *beim Ausgeben* als HTML mit den dafür vorgesehenen Funktionen kontextgerecht behandeln.
OK, ich kann nun mit htmlspecialchars() alle HTML-Tags 'maskieren'. Wie bekomme ich aber nun die Backslashes vernünftig weg? Und warum werden solche Backslashes überhaupt in der Datenbank gespeichert? Ich dachte, die werden nur wegen dem Kontextwechsel davor gesetzt. Soll heißen, wenn ich
INSERT INTO table SET text='Hallo 'welt''
habe, müsste in der Tabelle folgendes drinstehen:
Hallo 'welt'
Warum steht da bei mir aber
Hallo 'welt'
?
Grüße, JN
Hallo,
Dann solltest Du sie *beim Speichern* in der Datenbank mit den dafür vorgesehenen Funktionen kontextgerecht behandeln.
OK, nun wende ich beim Speichern mysql_real_escape_string() an.
Dann werden alle Anführungszeichen in der Datenbank mit Backslashes gespeichert.
das ist falsch. Richtig ist, dass mysql_real_escape_string() die Anführungszeichen mit Backslashes maskiert. Diese Maskierung macht mySQL aber automatisch wieder rückgängig, *bevor* die Daten in die DB eingetragen werden. Die Maskierung ist nur für die Übergabe von PHP an mySQL gedacht.
Dann solltest Du sie *beim Ausgeben* als HTML mit den dafür vorgesehenen Funktionen kontextgerecht behandeln.
OK, ich kann nun mit htmlspecialchars() alle HTML-Tags 'maskieren'. Wie bekomme ich aber nun die Backslashes vernünftig weg?
Die dürften im Normalfall gar nicht da sein.
Und warum werden solche Backslashes überhaupt in der Datenbank gespeichert? Ich dachte, die werden nur wegen dem Kontextwechsel davor gesetzt. Soll heißen, wenn ich
INSERT INTO table SET text='Hallo 'welt''
habe, müsste in der Tabelle folgendes drinstehen:
Hallo 'welt'
Warum steht da bei mir aber
Hallo 'welt'
?
Sind deine GET/POST-Daten vielleicht schon verstümmelt, wenn dein Script sie bekommt? Sind auf deinem Server bzw. in dessen PHP-Konfiguration vielleicht die bösen "magic quotes" aktiviert?
Ciao,
Martin
Moin allerseits,
Sind deine GET/POST-Daten vielleicht schon verstümmelt, wenn dein Script sie bekommt? Sind auf deinem Server bzw. in dessen PHP-Konfiguration vielleicht die bösen "magic quotes" aktiviert?
Yes, that's the problem!
Grüße, JN
Hi!
Sind deine GET/POST-Daten vielleicht schon verstümmelt, wenn dein Script sie bekommt? Sind auf deinem Server bzw. in dessen PHP-Konfiguration vielleicht die bösen "magic quotes" aktiviert?
Yes, that's the problem!
Lo!
Moin allerseits,
Hi!
Sind deine GET/POST-Daten vielleicht schon verstümmelt, wenn dein Script sie bekommt? Sind auf deinem Server bzw. in dessen PHP-Konfiguration vielleicht die bösen "magic quotes" aktiviert?
Yes, that's the problem!
Danke, das habe ich so bereits realisiert. Eine Anfrage an den internen Support zur Änderung ist bereits gestellt, solange nutze ich das workaround.
Grüße, JN