SQL mysql_real_escape_string fügt kein \ ein?

[Mr. Snoot]

Hü,

mal ne Frage. Wenn ich Daten in eine DB schreibe, soll man ja wegen Hochkomma etc. mysql_real_escape_string verwenden, um diesen Zeichen einen Slash voranzustellen. Also bspw. so:

$wert = "don't do this";
$eintrag = sprintf("INSERT INTO tabelle (feld) VALUES ('%s')", mysql_real_escape_string($wert);

Wenn ich mir den Wert dann aber direkt in der DB anschaue, stehen die Sonderzeichen dort unmaskiert drin, also keine Spur von \ o.ä. Gehe ich recht in der Annahme, dass der Slash quasi nur während des Schreibvorgangs gesetzt, aber nicht wirklich eingefügt wird? Oder mach ich was falsch?

Ich dachte bisher eigentlich, dass der Slash dann auch wirklich in der DB steht.

 

[Darii]

Gehe ich recht in der Annahme, dass der Slash quasi nur während des Schreibvorgangs gesetzt, aber nicht wirklich eingefügt wird?

Ja, du maskierst damit Sonderzeichen für die Datenbankanfrage. Guck dir $eintrag an, dann siehst du es. Nimm aber lieber prepared statements da musst du dir über sowas keine Gedanken mehr machen.

 

[Mr. Snoot]

Okay, danke. Dann habe ich die Slashes, die bisher drin stehen, wohl irgendwann mal von Hand eingefügt

 

[DerEineDa]

Du musst bedenken, dass du die Hochkommas ja auch selber maskieren müsstest, wenn du manuell mit einem SQL-Query-Tool etwas in eine Datenbank einträgst:

INSERT INTO tabelle(spalte) VALUES('Test '' Test')

Da erscheint dann auch nur "Test ' Test" in der Tabelle. Genau das (und weiteres) macht diese PHP-Funktion eben auch.

 

[Mr. Snoot]

Ja schon. Nur wenn ich es selbst maskiere, steht der \ ja anschließend auch in der DB; und ich dachte, genau das macht mysql_r._e._s. auch.

 

[Destruction]

Mysql_real_escape_string ändert den string nur für die mysql_query Abfrage.
Das was du willst ist mysql_escape_string
Viel Glück

MfG
Destruction

 

[Mr. Snoot]

Nein, nein - wollen tu ich das nicht. Hatte mich nur gewundert, warum kein \ in der DB auftaucht Ich dachte, dass vielleicht was falsch ist.

 

[BerniG]

Ja schon. Nur wenn ich es selbst maskiere, steht der \ ja anschließend auch in der DB; und ich dachte, genau das macht mysql_r._e._s. auch.

Vielleicht hat bzw. hatte dein PHP-Server magic_quotes aktiviert? http://www.php.net/manual/de/security.magicquotes.php Das wäre eine gute Erklärung für die praktisch doppelte Maskierung...

 

[Mr. Snoot]

Ne, eigentlich nicht; seit ich mit PHP angefangen habe waren hier magic_quotes immer off.

 

[DerEineDa]

Ich verstehe das Problem noch nicht - oder eigentlich glaube ich, dass du das nicht richtig verstehst. Die Funktion fügt \ ein, damit der SQL-Parser die maskierten Zeichen als solche versteht und sie als Inhalt einer Zeichenkette interpretiert, anstatt als Steuerzeichen. Ich verstehe also nicht, wieso du die Backslashes in der Datenbank erwartest - da sollen die Zeichen selbstverständlich so drin stehen, wie es sich gehört. Also ohne Maskierungszeichen.

Die Funktion ist also dafür da um Code-Injections zu verhindern. Wenn du also eine SQL-Abfrage hast, in der Art von "DELETE FROM users WHERE passwd = '$pass'" (rein theoretisches Konstrukt), wo der Benutzer da sein Passwort einsetzt damit sein Account gelöscht wird, dann solltest du $pass durch besagte PHP-Funktion laufen lassen. Sonst könnte er nämlich sowas als Passwort eingeben:

irgendwas' OR '1=1

Aus der SQL-Abfrage wird nun:

DELETE FROM users WHERE passwd = 'irgendwas' OR '1=1'

mysql_real_escape_string() kann aus $pass dann sowas machen:

irgendwas\' OR \'1=1

Die Abfrage sieht dann so aus:

DELETE FROM users WHERE passwd = 'irgendwas\' OR \'1=1'

Nun interpretiert der SQL-Parser die Hochkommas nicht mehr als Steuerzeichen, sondern als normales Zeichen innerhalb einer Zeichenkette, so dass in dem Beispiel nur noch Benutzer mit dem Passwort

irgendwas' OR '1=1

gelöscht werden.

Es gibt auch gar keine andere Möglichkeit Hochkommas in eine Tabelle einzutragen, deswegen verstehe ich nicht, wieso du die Backslashes in der Tabelle erwartest. Sie dienen nur dazu, um dem SQL-Parser mitzuteilen, dass diese Hochkommas nun nicht das Ende eines Strings darstellen.