php.net schreibt:
Characters encoded are NUL (ASCII 0), \n, \r, , ', ", and Control-Z.
Die folgende Query erwartet einen numerischen Parameter (als PHP-String mit string parsing):
$sql = "select foo,bar from atable where key=$keyValue"
Wenn ich es schaffe, hier statt bspw. 4711 den "Wert" 1 OR 1=1
zu injizieren, hilft mir Escaping jeglicher Art nicht weiter. Oder schlimmer noch: 1; DROP atable
. Das Semikolon wird nicht escaped.
Wenn der Variableninhalt, der in die Query eingesetzt wird, im SQL String in Anführungszeichen gesetzt wird, bin ich mit Escaping vermutlich sicher, weil ich dann nicht mehr aus dem String hinauskomme. Ob spezielle Multibyte-Zeichensätze trotzdem ein Schlupfloch aus dem String hinaus ermöglichen, weiß ich nicht.
Trotzdem ist SQL mit direkt eingesetzten Werten ein Kopfschmerzgenerator und daher würde ich dann, wenn zugelieferte Werte als Parameter zu nutzen sind, prepared statements immer vorziehen, auch wenn das einen zusätzlichen Roundtrip zum SQL Server bedeutet. Wenn man Hochlast-Sites baut, in denen das zum Problem werden kann, muss man ohnehin ganz andere Mechanismen zur Laststeuerung bzw. -reduktion einsetzen.
Rolf