La respuesta corta es NO, PDO prepares no lo defenderá de todos los posibles ataques de inyección SQL. Para ciertos bordes oscuros-casos.

Estoy adaptandoesta respuesta para hablar de DOP...

La respuesta larga no es tan fácil. Se basa en un ataque demostrado aquí.

El ataque

Entonces, comencemos mostrando el ataque...

$pdo->query('SET NAMES gbk');
$var = "\xbf\x27 OR 1=1 /*";
$query = 'SELECT * FROM test WHERE name = ? LIMIT 1';
$stmt = $pdo->prepare($query);
$stmt->execute(array($var));

En ciertas circunstancias, eso devolverá más de 1 fila. Vamos a diseccionar lo que está pasando aquí:

1. Seleccionar un Conjunto de Caracteres

   $pdo->query('SET NAMES gbk');
   

   Para que este ataque funcione, necesitamos la codificación que el servidor espera en la conexión tanto para codificar ' como en ASCII i. e.0x27 y tener algún carácter cuyo byte final es un ASCII \ es decir, 0x5c. Resulta que hay 5 tales codificaciones soportadas en MySQL 5.6 por defecto: big5, cp932, gb2312, gbk y sjis. Vamos a seleccionar gbk aqui.

   Ahora, es muy importante notar el uso de SET NAMES aquí. Esto establece el conjunto de caracteres EN EL SERVIDOR. Hay otra forma de hacerlo, pero lo conseguiremos pronto.

2. La Carga útil

   La carga útil que vamos a usar para esta inyección comienza con la secuencia de bytes 0xbf27. En gbk, es un carácter multibyte no válido; en latin1, es la cadena ¿'. Tenga en cuenta que en latin1 y gbk, 0x27 por su cuenta es un carácter literal '.

   Hemos elegido esta carga porque, si llamamos addslashes() en ella, insertaríamos un ASCII \, es decir, 0x5c, antes del carácter '. Así que terminaríamos con 0xbf5c27, que en gbk es una secuencia de dos caracteres: 0xbf5c seguido de 0x27. O en otras palabras, un carácter válido seguido de un ' sin escapatoria. Pero no estamos usando addslashes(). Así que al siguiente paso...

3. $stmt- > ejecutar()

   Lo importante lo que hay que tener en cuenta aquí es que PDO por defecto hace NO hacer verdaderas declaraciones preparadas. Los emula (para MySQL). Por lo tanto, PDO construye internamente la cadena de consulta, llamando a mysql_real_escape_string() (la función API de MySQL C) en cada valor de cadena enlazada.

   La llamada de la API C a mysql_real_escape_string() difiere de addslashes() en que conoce el conjunto de caracteres de conexión. Por lo que puede realizar el escape correctamente para el conjunto de caracteres que el servidor está esperando. Sin embargo, hasta este punto, el cliente piensa que estamos seguimos usando latin1 para la conexión, porque nunca le dijimos lo contrario. Le dijimos al servidor que estamos usando gbk, pero el cliente todavía piensa que es latin1.

   Por lo tanto, la llamada a mysql_real_escape_string() inserta la barra invertida, y tenemos un carácter de suspensión libre ' en nuestro contenido "escapado"! De hecho, si tuviéramos que mirar $var en el conjunto de caracteres gbk, veríamos:

   縗' OR 1=1 /*

   Que es exactamente lo que requiere el ataque.

4. Las Query

   Esta parte es solo una formalidad, pero aquí está la consulta renderizada:

   SELECT * FROM test WHERE name = '縗' OR 1=1 /*' LIMIT 1
   

Felicitaciones, acaba de atacar con éxito un programa utilizando Declaraciones preparadas PDO...

La Solución Simple

Ahora, vale la pena señalar que puede evitar esto deshabilitando las declaraciones preparadas emuladas:

$pdo->setAttribute(PDO::ATTR_EMULATE_PREPARES, false);

Esto normalmente dará como resultado una verdadera declaración preparada (es decir, los datos que se envían en un paquete separado de la consulta). Sin embargo, tenga en cuenta que PDO silenciosamente recurrirá a la emulación de instrucciones que MySQL no puede preparar de forma nativa: las que puede están listadas en el manual, pero tenga cuidado de seleccionar la versión del servidor apropiada).

La Solución correcta

El problema aquí es que no llamamos a la API de C mysql_set_charset() en lugar de SET NAMES. Si lo hiciéramos, estaríamos bien siempre y cuando estemos usando una versión de MySQL desde 2006.

Si está utilizando una versión anterior de MySQL, entonces una el error en mysql_real_escape_string() significaba que los caracteres multibyte no válidos, como los de nuestra carga útil, se trataban como bytes individuales para fines de escape incluso si el cliente había sido informado correctamente de la codificación de conexión y, por lo tanto, este ataque seguiría teniendo éxito. El error fue corregido en MySQL 4.1.20, 5.0.22 y 5.1.11.

Pero la peor parte es que PDO no expuso la API de C para mysql_set_charset() hasta la versión 5.3.6, por lo que en versiones anteriores no puede prevenir este ataque por cada orden posible! Ahora está expuesto como un parámetro DSN , que debe usarse en lugar de SET NAMES...

La Gracia Salvadora

Como dijimos al principio, para que este ataque funcione, la conexión a la base de datos debe codificarse utilizando un conjunto de caracteres vulnerable. utf8mb4 es no vulnerable y, sin embargo, puede soportar cada carácter Unicode: por lo que podría elegir usar eso en su lugar,pero tiene solo está disponible desde MySQL 5.5.3. Una alternativa es utf8, que también es no vulnerable y puede soportar la totalidad del Plano Multilingüe Básico Unicode .

Alternativamente, puede habilitar el NO_BACKSLASH_ESCAPES Modo SQL, que (entre otras cosas) altera el funcionamiento de mysql_real_escape_string(). Con este modo habilitado, 0x27 se reemplazará por 0x2727 en lugar de 0x5c27 y, por lo tanto, el proceso de escape no puede crear caracteres válidos en cualquier de las codificaciones vulnerables donde no existían previamente (es decir, 0xbf27 sigue siendo 0xbf27 etc.)- por lo que el servidor rechazará la cadena como no válida. Sin embargo, ver @eggyal's answer para una vulnerabilidad diferente que puede surgir del uso de este modo SQL (aunque no con PDO).

Ejemplos seguros

Los siguientes ejemplos son seguros:

mysql_query('SET NAMES utf8');
$var = mysql_real_escape_string("\xbf\x27 OR 1=1 /*");
mysql_query("SELECT * FROM test WHERE name = '$var' LIMIT 1");

Porque el servidor está esperando utf8...

mysql_set_charset('gbk');
$var = mysql_real_escape_string("\xbf\x27 OR 1=1 /*");
mysql_query("SELECT * FROM test WHERE name = '$var' LIMIT 1");

Porque hemos establecido correctamente el conjunto de caracteres el cliente y el servidor coinciden.

$pdo->setAttribute(PDO::ATTR_EMULATE_PREPARES, false);
$pdo->query('SET NAMES gbk');
$stmt = $pdo->prepare('SELECT * FROM test WHERE name = ? LIMIT 1');
$stmt->execute(array("\xbf\x27 OR 1=1 /*"));

Porque hemos desactivado las declaraciones preparadas emuladas.

$pdo = new PDO('mysql:host=localhost;dbname=testdb;charset=gbk', $user, $password);
$stmt = $pdo->prepare('SELECT * FROM test WHERE name = ? LIMIT 1');
$stmt->execute(array("\xbf\x27 OR 1=1 /*"));

Porque hemos establecido el conjunto de caracteres correctamente.

$mysqli->query('SET NAMES gbk');
$stmt = $mysqli->prepare('SELECT * FROM test WHERE name = ? LIMIT 1');
$param = "\xbf\x27 OR 1=1 /*";
$stmt->bind_param('s', $param);
$stmt->execute();

Porque MySQLi hace verdaderas declaraciones preparadas todo el tiempo.

Terminando

Si usted:

• Use versiones modernas de MySQL (finales de 5.1, todas 5.5, 5.6, etc.) Y Parámetro de conjunto de caracteres DSN de PDO (en PHP ≥ 5.3.6)

O

• No use un conjunto de caracteres vulnerables para la codificación de conexión (solo use utf8 / latin1 / ascii / etc)

O

• Habilitar NO_BACKSLASH_ESCAPES Modo SQL

Estás 100% a salvo.

De lo contrario, eres vulnerable a pesar de que estás usando Declaraciones preparadas por PDO...

Adición

He estado trabajando lentamente en un parche para cambiar el valor predeterminado para no emular se prepara para una versión futura de PHP. El problema que soy encontrarme es que muchas pruebas se rompen cuando hago eso. Un problema es que emulated prepares solo lanzará errores de sintaxis en execute, pero true prepares lanzará errores en prepare. Por lo que puede causar problemas (y es parte de la razón por la que las pruebas están borking).