¿Las consultas dinámicas de mysql con sql escapan son tan seguras como las declaraciones preparadas?

Question

Tengo una aplicación que se beneficiaría enormemente al usar consultas dinámicas de mysql en combinación con mysql (mysqli) cadena de escape real. Si ejecutara todos los datos recibidos del usuario a través de mysql escape real, ¿sería tan seguro como usar las declaraciones preparadas de mysql?

Answer 1

Definitivamente NO.

Mientras pregunta del título es ambiguo y puede ser interpretado como "son consultas MySQL dinámicos con cada es parte correctamente formateado ..." y así tener una respuesta positiva, la pregunta en el cuerpo es no:

Si me encontré con todos los datos recibidos desde el usuario a través de escape real de MySQL sería tan seguro como el uso de MySQL preparado estados?

Si se mira más de cerca a esta pregunta, se entiende que esto es sólo una magia cita encarnación! El verdadero propósito de esta característica deshonrada, desaprobada y eliminada es exactamente "ejecutar toda la entrada del usuario a través de escape".
Todo el mundo sabe hoy en día que las comillas mágicas son malas. ¿Por qué una respuesta positiva?

De acuerdo, parece que debe explicarse de nuevo, por qué el escape a granel es malo.

La raíz del problema es una ilusión bastante fuerte, compartida por casi todos los usuarios de PHP:
Todo el mundo tiene una extraña creencia de que escapen hacer algo sobre los "caracteres peligrosos" (? Qué están) haciéndolos "seguro" (¿cómo?). Huelga decir que no es más que una basura completa.

La verdad es:

• Escapar no "desinfectar" nada.
• Escapar no tiene nada que ver con las inyecciones.
• El escape no tiene nada que ver con la entrada del usuario.

Escapar no es más que una cadena de formatear y nada más.
Cuando lo necesite, lo necesita a pesar de la posibilidad de inyección.
Cuando no lo necesite, no servirá de nada contra la inyección.

Hablando de diferencia con declaraciones preparadas, hay por lo menos un tema (que ya se ha mencionado muchas veces bajo sql-injection etiqueta):
un código como este

$clean = mysql_real_escape_string($_POST['some_dangerous_variable']); 
$query = "SELECT * FROM someTable WHERE somevalue = $clean"; 

le ayudará no en contra de la inyección.
Beause escaping es solo un recurso de formateo de cadenas, no un preventor de inyecciones de ninguna manera.
Vaya figura.

Sin embargo, escapar de tener algo en común con declaraciones preparadas:
los dos no le garantiza de inyección si

• está utilizando sólo contra la "entrada del usuario" notorio, no como una regla estricta para la construcción de CUALQUIER consulta, a pesar de la fuente de datos.
• en caso de que necesite insertar no datos, sino un identificador o una palabra clave.

ser segura en estas circunstancias, ver mi respuesta explicando FULL sql injection protection how-to

Larga historia corta: usted puede considerarse segura sólo si realiza 2 correcciones esenciales y una adición a su declaración inicial:

Si me encontré con todos los datos recibido del usuario a través verdadero escape MySQL y siempre entre comillas (y, como ircmaxell mencionado, mysqli_set_charset() se utiliza para hacer mysqli_real_esc ape string() en realidad hace su trabajo (en una ocasión tan rara de usar alguna codificación extraña como GBK) ¿Sería tan seguro como usar las declaraciones preparadas de mysql?

Siguiendo estas reglas - Sí, sería ser tan seguro como declaraciones preparadas nativos.

Answer 2

Sí, pero es un sí calificado.

Es necesario que escape correctamente el 100% de la entrada. Y debe establecer correctamente conjuntos de caracteres (si está utilizando la API C, debe llamar al mysql_set_character_set() en lugar de SET NAMES). Si te pierdes una pequeña cosa, eres vulnerable. Entonces sí, siempre y cuando lo haga todo bien ...

Y esa es la razón por la que mucha gente recomendará consultas preparadas. No porque sean más seguros. Pero porque son más indulgentes ...

Answer 3

Creo que @ircmaxell lo hizo bien.

Como seguimiento, esté atento a este tipo de cosas.
Solía ​​hacerlo todo el tiempo:

<?php 

//sanitize the dangerous posted variable... 
$clean = mysql_real_escape_string($_POST['some_dangerous_variable']); 

//...and then forget to use it! 
$query = "SELECT * FROM someTable WHERE somevalue = '{$_POST['some_dangerous_variable']}'"; 

?> 

Y cuando digo "que se utiliza para hacerlo", lo que quiero decir es que con el tiempo me di por vencido y acaba de empezar a usar comandos preparados!