leí que con DOP que no es necesario para escapar de las variables si se utiliza preparar y pasar las variables de ejecutar:¿Debo escapar de la entrada de DB?
$st = $dbh->prepare("INSERT INTO mytable (name,email) VALUES (?,?)");
$st->execute(array($_POST['name'], $_POST['email']));
¿Es esta tru?
¿O todavía tengo que hacer algo con $ _POST allí?
En sentencias preparadas, no es necesario escaparse (y el escaparse de las cosas generará doble escape, lo que provocará que los datos escapados se escriban en la base de datos).
Sin embargo, las declaraciones preparadas con PDO NO PUEDEN manejar todas las variantes de consulta, y algunas veces tendrá que insertar datos "foráneos" directamente en una cadena de consulta, lo que significa que será responsable de escapar correctamente. En particular, las consultas dinámicas en las que cambian los nombres de tabla y/o campo no pueden especificarse utilizando instrucciones preparadas. p.ej.
SELECT ? FROM ? WHERE ?=?
no se puede hacer. Solo los valores pueden especificarse con marcadores de posición.
seleccionar? donde? = no parece funcionar. Al parecer, solo los valores pueden tener? ... – JohnSmith
Exactamente. los campos y los nombres de tabla no se pueden especificar con marcadores de posición. –
Respuesta corta: No, no necesita escapar de nada. Las consultas parametrizadas son ¡totalmente increíbles! :)
Respuesta larga: No, no es necesario para escapar nada ya que va en la base de datos. Sin embargo, aún debe usar htmlspecialchars al mostrar la salida de la base de datos de las consultas para evitar ataques XSS, de lo contrario terminará con alguien rellenar algo como esto en un campo arbitrario:
<script type="text/javascript">alert('sup, I'm in ur site!');</script>.
Destacando * cuando se muestra la salida de la base de datos *. En general, debe ** no ** almacenar HTML en la base de datos a menos que su campo sea realmente HTML. – phihag
Esto es cierto; el código es correcto (aunque es posible que desee manejar el caso en el que $_POST['name'] no está configurado).
La funcionalidad de declaración preparada de PDO entrega los valores en un formato que no necesita el escape explícito.
Es algo importante tener en cuenta que PDO no escapa, sino que aísla por completo los datos del lenguaje de consultas. – Polynomial
@Polynomial Gracias, actualizado. – phihag
A pesar de que no necesita escaparse, asegúrese de verificar la cordura, los rangos aceptables, el correo electrónico con el formato correcto, etc., y devolver los mensajes de error a su usuario cuando corresponda. –
sí, tenía curiosidad por los ataques sql – JohnSmith
Siempre que sea estricto con lo que coloca en su consulta y dónde lo hace (es decir, use parámetros en todo momento, nunca * nunca * permita que los datos proporcionados por el usuario se filtren en partes concatenadas de consultas dinámicas) entonces estarás a salvo. – Polynomial