Tach!
Es bleibt sich also gleich, ob man die notwendigen Backslash- und Quote-Zeichen mit mysqli_real_escape_string(), mit addslashes() oder einer beliebigen anderen Funktion maskieren lässt.
Bis in einer zukünftigen MySQL-Version weitere Zeichen dazukommen, die von addSlashes nicht erfaßt werden.
Wer gibt denn eine Garantie, dass mysql(i)_real_escape_string()[1] die Funktion ist, die in der Zukunft den (unwahrscheinlichen) Fall abdeckt, hinzukommende für SQL-Injection relevante Zeichen oder andere Umstände zu berücksichtigen?
Verwendet man gleich die dafür vorgesehene Funktion mysqli_real_esacpe_string statt einer, die derzeit zufällig fast das gleiche macht, ist man auf der sicheren Seite.
mysql_escape_string() wurde mit PHP 4.1 eingeführt. Davor gab es nur addslashes() (Magic Quotes ignorieren wir mal). Damals hieß es schon, dass man von addslashes() auf die mysql-eigene Funktion umsteigen solle. Aber war das zukunftssicher? Jedenfalls kam mit PHP 4.3 dann mysql_real_escape_string() dazu, weil die Funktion zwar die notwendigen Zeichen (plus Zusatzzeichen \n, \r, ^Z) behandelt hatte, aber nicht berücksichtigt hatte, dass es Zeichenkodierungen abseits von ASCII-basierenden gibt, bei denen die Funktion versagte. Man hat sie nicht gändert, sondern die neue Funktion mysql_real_escape_string() dazugegeben. Die alte Funktion wurde nicht erweitert, weil sie wegen eines neuen Pflichtparameters nicht kompatibel war.
Aus der Geschichte kann man schlecht auf die Zukunft schließen ... aber ... es gibt bereits einen Nachfolger in der MySQL-Client-API, mit dem Namen mysql_real_escape_string_quote(). Man hat eine Situation gefunden hat, in der mysql_real_escape_string() nicht ausreicht. Die neue Funktion benötigt einen zusätzlichen Parameter, weswegen die alte Funktion nicht abwärtskompatibel weiterverwendet werden kann. In PHP ist die Funktion noch nicht angekommen. Mit der Aussage, mysql(i)_real_escape_string() sei zukunftssicher, würde ich mich jedenfalls schwertun.
dedlfix.
In PHP mit i, in der MySQl-Client-API ohne i. ↩︎